ASP.NET MVC - 将服务器端事件传播到客户端

Question

In my ASP.NET MVC app, the user clicks a button on the UI to make a phone call. An ajax request goes to the MVC app, which calls a phone dialer -- a method in library that calls an external component to make a call.

If a dialed call is terminated by the recipient of the call, the phone dialer component raises an event by calling an event handler in its own class.

I want to propagate that event to the client side so that it may update its UI.

An Option I Can't Use

I've looked at JavaScript Server-sent events. However, they are different from my situation in the way that in a JavaScript Server-sent event, here's what happens:

1) The client initiates a connection on a new socket to the server. The key difference being, the client initiates the connection.

2) The connection is held live and active until the server or the client want to terminate it.

3) The server has to be alive all throughout the time from the time the connection is made until the client or the server want to terminate the connection and no longer exchange notifications. This means that a new socket connection and consequently a new worker thread to service the notification exchange is used per client.

If I use server-sent events, I will have to make a server that stays alive. That means I will have to have a new action on a controller and a corresponding view that gets called at the very beginning and stays alive until the notification about the call hang-up is received.

This can not only be expensive, it is also counter-intuitive to my design as I do not want to be redirected to a new View just to listen to events.

Anyone have any other alternative?

Answer 1

You have to either use a WebSocket or Long polling . These both require you to set up a connection from the client to the server, additional to the normal HTTP cycle. And what else would you expect? When the page is sent, the communication between client and server is done. The HTTP cycle is over, no more data can float through. The new connection needs to originate from the client because the client does not allow arbitrary incoming connections.

Answer 2

I do not think there are other alternatives in normal case.

SignalR, etc, all require connection to be alive or periodically restarted by client. I am not aware of anything that allows server to initiate connection with a browser (it does not even seem technically possible due to proxies/firewalls etc).