I have a use case where we will have an ASP.NET MVC Server Application but it needs to talk over a persistent connection to a Windows service. It doesn't look like SignalR does this as it really wants talk Server to JavaScript browsers but I did notice .NET desktop libraries. Can it talk from a server to a Windows server? If not, is there a recommended way, TCP/IP or HTTP to have a persistent connection between the two? NetTcpBinding in WCF?
Yes, there is a SignalR client library for .NET that you can use in any old .NET app to talk to a SignalR server just like you can from JavaScript.
While there is a WebSockets binding for WCF, there is no binding that actually talks native SignalR which adds its own message framing on top of raw web sockets. So, while possible, it doesn't exist today and I wouldn't hold my breath for it ever being created.
Why not simply have a queue using RabbitMQ. And anytime the web need to talk to window service, it push a message into the queue while the window service listen to the queue
Related
I have some questions regarding SignalR Core on the server side;
My server is written in ASP.NET Core, and it uses SignalR for sending notifications to users. The server uses Controllers with endpoints that clients interact with.
1) Can I host the entire thing in Azure App Service and add the SignalR service to it? Or would it be better to split the SignalR code out to its own server, which is called from the "main" server when needed?
2) The SignalR Service has an option for "Serverless", which according to documentation doesn't support clients calling any server RPCs when in said mode. Could I run this thing in Serverless mode as I'm only using the sockets for sending notifications to the clients. Or is it reserved for Azure functions?
3) Is there a way to get the number of connections for a user in a SignalR hub? I would like to send a push message to the user if he doesn't have any connections to the server. If not - what is the recommended way of handling this? I was thinking of adding a singleton service that keeps count, but am unsure if this would work at scale, especially with the SignalR service.
Thanks.
1) Better use the Azure SignalR.
2) Use it with the hub.
3) If you use Azure SignalR, you can just see it from the portal. In the code, whenever you use Azure SignalR or not, you can save the user Id in some var and count the connections. If you have multiple hubs and servers, you need to do more (if using redis-backplane for example).
I am in a stage of using SignalR in my project and i don't understand when to use Self hosted option and when we should not use. As a example if I am willing to host my web application in server farm,
There will be separate hosting servers
Separate SignalR hubs in each IIS server
If we want to broadcast message into each client, how this is working in SignalR
The idea with SignalR running in multiple instances is that clients connected on instance A cannot get messages from clients connected to instance B.
(SignalR scaleout documentation)
However, when you scale out, clients can get routed to different
servers. A client that is connected to one server will not receive
messages sent from another server.
The solution to this is using a backplane - everytime a server recieves a message, it forwards it to all other servers. You can do this using Azure Service Bus, Redis or SQL.
The way I see, you use the self host option when you either don't want the full IIS running (because you have some lightweight operations that don't require all IIS heaviness) or you don't want a web server at all (for example you want to add real-time functionality to an already existing let's say forms application, or in any other process).
Be sure to read the documentation for self-hosting SignalR and decide whether you actually need to self host SignalR.
If you are developing a web application under IIS, I don't see any reason why you would want to self-host SignalR.
Hope this helps. Best of luck!
My team is in the middle of deciding the architecture of our backend system:
Webserver A is an ASP.NET MVC application with ASP.NET Web API component, hosted in Azure Website.
Windows Service B is a self-hosted OWIN server that will periodically push notifications to clients who subscribes to the notification, hosted in Azure VM.
Windows Service C is a client that subscribes to notification from B, hosted in Azure VM.
Since we are more-or-less entrenched in .NET stack, we implemented B as SignalR server with C being the SignalR client. This part seems to work well.
Now comes a point where we also want A to subscribe to B, but I realize that it means an ASP.NET Web Server is going to act as SignalR CLIENT, instead of the typical scenario where it acts as SignalR server.
I presume we can initialize the SignalR connection in Global.asax and make the process ever-running to avoid AppDomain recycle. However, I feel a bit iffy when a Web Server is made to do something other than serving web requests. This solution also make the web server not stateless since it needs to maintain the web socket connection alive.
Is there something fundamentally wrong with making an ASP.NET application a SignalR client? Is there any possible gotcha with this setup?
In Azure you cannot tell that your AppDomain will not recycle. Because of many reasons, it can restart itself to heal and then you will end up making a new connection to the SingleR server. Is that OK for you?
Also SingleR is mostly used in the Web Functionality improvement where polling and refresh on web clients is made simple. But as your requirement seems to be all a back end stuff, I would suggest you to go with any other event driven pattern. Check Azure Service Bus topic/subscription model to have different components listen to various events and act accordingly.
There is a WCF Windows Service listening in netTcpBinding protocol, which I understand is Microsoft's proprietary protocol (correct me if i am wrong). I need to write a website that will consume the WCF services. I know for certain PHP can only connect to WCF Service in SOAP (basicHttpBinding or wsHttpBinding) so I need to write another SOAP proxy.
Some comments on the internet suggest that it is possible to have ASP.NET website connect to a WCF Service via net.tcp protocol. Is this actually true? Where should I look?
Your understanding about the netTcpBinding is correct. It is proprietary and accessible only from .NET clients. Since ASP.NET is .NET you could consume your WCF service without any problems.
Ofcourse an ASP.NET web application can connect to a WCF service using net.tcp binding but not over the internet! If the application and the service arn't on the same server or in the same intranet it will not work, you have to choose a HTTP binding.
From my comment below:
Yes net.tcp can work over the internet but not every circumstances it's not recommended (check it at MSDN) to use it. Ofcourse if the whole server control is our we can give it a try but if not (the application and service hosted by a 3rd party member) the chances are not so high to get it work (for example port blocking, the net.Tcp listener is disabled, net.Tcp port sharing is not working or disabled)
I want to create a socket on the client to listen for notifications from the server. Is there any example of a socket server built that I can use in my asp.net application?
Asp.net is state-less you would need to build a windows service or windows application to publish a socket end-point unless you are looking at something like Comet?
Asp.net cannot fire server events if there is no intervention by a process or a user.
Can you describe your requirement a bit better?
https://github.com/SignalR/SignalR is a Server side and client side implementation of Comet it looks like a suitable solution for messaging purposes what are you attempting to build this might give more insight to a suitable solution.