I am porting a PERL (.pl file) which is a socket listener, which is hosted on IIS web server. A PERL client just opens a socket connection to this PERL server and start transferring data.
What ASP.NET technologies (without webpage and webservice) is the equivalent of this PERL service. Is there a ASP.NET web template that is ideal to just add the websocket C# code and have it always up and listening to a port for incoming traffic and be hosted on the IIS (Just like the PERL file and its simplicity. I am not looking for WCF answer. And how would it be configured on the IIS?
Thanks
Theres a few options here, if the socket is HTTP based then you could have a peek at Custom Handlers, these transfer everythign through HTTP though. If you are looking for just a socket which doesn't handle HTTP then you're probably not going to want to do that in IIS/ASP.NET but rather a C# Service, have a peek at a C# tutorial for multithreaded services. You can easily port this code into a service.
The problem is that IIS is really designed to be a HTTP/HTTPS protocol so your trying to force it to do things it wasn't designed for, you could go down the route of custom ISAPI modules, and HTTP modules but again you'd be trying to fit a square peg in a round hole.
Related
Recently I talked with some developers, and they said that they call one endpoint from their front-end (web app) and that endpoint is a web socket. All their REST calls go through this connection. This solution was in Java. So I started wondering how they do that. How they dispatch the endpoint, what is the payload, etc. but in Asp.NET Core.
I am wondering is it possible and how.
I see this is very interesting topic. I found this useful- https://developer.okta.com/blog/2019/11/21/csharp-websockets-tutorial
You can do this in dotnet core using SignalR: https://learn.microsoft.com/en-us/aspnet/core/signalr/introduction?view=aspnetcore-5.0
I think you're mixing two different technologies.
A REST endpoint belongs to WebServices and is an url, pointing to one or more methods in your code that can accept parameters and return results in XML/JSON format.
You can then fetch this url from your front-end and read the response.
An example of REST webservice is Google Maps API.
A Websocket, instead, is a continuous connection and works as a plain socket but between a webpage running on a client and another server application on another machine (i.e. the server).
It's used when you need an open tunnel with continuous exchange of data: chats, video and audio streaming, multiplayer games and more.
You cannot make a REST call to a websocket endpoint and if you want to use websockets you must write a server in C# (i use .net core). A console application.
I'm unsure what you are looking for exactly. If you want to start with websockets, this is where i started from:
Writing websocket server
Writing a websocket server in C#
For webservices:
Writing a web service in ASP.NET
I'm new to gRpc and now learning this tech
I'm wondering if gRpc can replace SignalR for updating notification bar on my client-side app (React).
Is that the case? or should I keep using SignalR for this matter?
(I'm asking it just to make sure I understand the purpose of the gRpc tech, by few articles I read it's more a web API replacement and few others compare it to SignalR)
Thanks!
y-me
Assuming you meant browser-based clients, then NO you cannot use gRPC. The gRPC protocol relies on HTTP/2 framing and in particular the ability to send and receive HTTP trailers. While browser themselves can and do use HTTP/2, current browser APIs (XHR/Fetch) don't expose HTTP/2 semantics.
There is however an alternative protocol, gRPC-web, that supports a subset of gRPC functionality you can utilize from a browser-based application. Given that it is a different protocol, your server will need to support it or you will need to employ a proxy like Envoy that can translate gRPC-web calls to gRPC.
I can't answer your question has if it is usable for Server/Client communications, just offer some thoughts. SignalR is made for the purpose of real time communications between Client and Server because of it's adaptability, and gRPC by it's constraints (HTTP/2 and HTTPS) is more reserved for backend micro-services communications.
I have an application in WPF c# which will run on client machine. Another application (maybe some kind of service) on a particular server will be running all the time and will wait for any incoming message from the client app. As soon as the server receives a request from any of the client application, it triggers a command line process and also responds to the client about the staring info(whether it was successful or not) and as well as when the command line process is finished it again responds to the calling client application that it got finished.
I am new to in this area.
So my question is should I use normal windows service or Web service or WCF?(Some kind of link to a demo project will really help). Any other suggestion are also welcomed.
You did not mention if your clients will be outside of your firewall or with in the same intranet. We have intranet scenario, and we use WCF service that communicates with WPF based applications over the internal network. WCF provides Duplex feature which enables two-way client server communication using an easy to implement programming model. I recently wrote an article on this and it can give you a head start for the WCF way.
However, WCF does not have the best support for callbacks over the internet and you may have to look in to effectively using it in your case. But if it is intranet, then my suggestion is surely to go for the WCF way. Hope it helps.
I'm looking for the simplest way of communicating between
A website with its logic written in C# and hosted in IIS
A C# windows service that is going to handle the long running operations
from the website
They're both on the same machine. I've worked with WCF services hosted in a windows service before but I think WCF isn't being worked on or improved anymore?
Ideally the communication will be as simple as calling a C# method, without having to worry about JSON/XML serialization and deserialization and it won't have all the overhead of a WCF service.
Other methods of communicating I've found online are
Sockets - I can't find a way for it to continuously listen on a TCP port without spinning in an infinite loop.
Named pipes - looks promising but I haven't worked with them before so it's hard to evaluate
Inter process communication. Still not sure what this is other than a catch all term for generic ways of communication outside of a process, like a shared text file.
I want to send data to a driver software via browser application with in same machine. If this driver can keep on listening to external connection via socket as a windows service, can I write a web application to send data to this driver by using php, applet or .net. Driver is written in C#. Is this possible and if so can someone show me a path/suggestions or any resource related to this?
I do not know a whole lot about drivers...
But, if you can self-host a WCF service in the C# driver, than you can do IPC (inter-process communication) on the same machine. The WCF could expose multiple endpoints ie.) http, namedpipe, or tcp and the .NET web application can subscribe to the service and send data to the C# driver.
Also, if you use a http or tcp endpoint, i believe that the web application would be able to connect to the C# driver from another machine.
WCF Reference: http://msdn.microsoft.com/en-us/library/ms731082.aspx
you could use web sockets WebSocket, however your driver would have to handle the handshake.