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.
Related
I am working on a project , client server based live meeting.
I connected two systems in same network. The system is sending mail to each other but cannot join in chat at same time .
I don't know exactly how to configure and connect web browser with server so that it can communicate.
What will be the problem not allowing to chat and please suggest any method to overcome this fault.
In desperate need of help..
Database is connected
You could use SignalR as a possible solution. It allows real-time functionality on your web site.
Take a look here: IM using SignalR
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.
I like SignalR and I am developing 2 things.
Server side code
Client web app
The challenge is that I need to allow the server to be implemented in a non .NET environments like may be Java or PHP. In that case the client will be using
"SignalR" libraries and server has to match the SignalR implementation on the server (in PHP, Java, etc). In a way, what I am after is shipping a server side API and a .NET signalr based implementation, but allow anyone to be able to implement the server side API in php/java etc
For this, what I need the API sequence and protocol signalR uses. I am kind of thinking that this is not going to happen because SignalR is matched on the client and server side to talk in specific way to make the magic possible.
Has anyone else been in this predicament? Any ideas on what the best way to proceed? By the way, before you ask the question, if it is a pure websockets based app, I will have less problems, I can just user WebSockets standard APIs.
However, I might need to fallback on long polling, because my server might need to run on Windows 7 - where websockets is not available.
Instead of reverse engineer the SignalR protocol make sure the clients do not have direct dependency on SignalR. Create client side adapters for the different server side framework. Include the correct adapter depending on server side platform
Here is a description of the SignalR protocol.
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
I'm sure that was a confusing enough title.
I have a long running Windows service dealing with things happening in the world. This service is my canonical source of truth for the rest of my system. Now I want to slap a web interface onto this so the clients can see what is actually going on. At first this would simply be a MVC5 application with some Web API stuff. Then I plan to use SignalR 2.0 and Ember.js to make this application more interactive and "realtime".
The client communicates with the Windows Service over named pipes using WCF. A client (such as a web app) could request an instance of for example IEventService, would be given a WCF proxy client, and could read about events through this interface. Simple enough.
However, a web application basically just exists in the sense that it responds to requests from the user. The way I understand it, this is not the optimal environment for a long lived WCF client proxy to raise events in, and thus I wonder how to host my SignalR stuff. Keep in mind that a user would log in to the MVC5 site, but through the magic of SignalR, they will keep interacting with the service without necessarily making further requests to the website.
The way I see it, there are two options:
1) Host SignalR stuff as part of the web app. Find a way to keep it "long-running" while it has active clients, so that it can react to events on the WCF client proxy by passing information out to the connected web users.
2) Host SignalR stuff as part of my Windows service. This is already long-running, but I know nada about OWIN and what this would mean for my project. Also the SignalR client will have to connect to a different port than where the web app was served from, I assume.
Any advice on which is the right direction to go in? Keep in mind that in extreme cases, a web user would log in when they get to work in the morning, and only have signalr traffic going back and forth (i.e. no web requests) for a full work day, before logging out. I need them to keep up with realtime events all that time.
Any takers? :)
The benefit of self-hosting as part of your Windows service is that you can integrate the calls to clients directly with your existing code and events. If you host the SignalR server separately, you'd have another layer of communication between your service and the SignalR server.
If you've already decided on using WCF named pipes for that, then it probably won't make a difference whether you self-host or host in IIS (as long as it's on the same machine). The SignalR server itself is always "long-running" in the sense that as long as a client is connected, it will receive updates. It doesn't require manual requests from the user.
In any case, you'll probably need a web server to serve the HTML, scripts and images.
Having clients connected for a day shouldn't be a problem either way, as far as I can see.