ASP.NET MVC - Propagate a server side event to the client - javascript

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?

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.

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).

Related

How to wait while the server doesn't respond?

I'm building a webpage with some interactions between users and I'm a bit lost.
Any guidance is welcome.
Imagine the following scenario:
Client A opens a 'public' webpage and pressess a button.
Client A starts waiting for the response of client B
Client B goes to an 'admin' webpage and presses a button.
Client A receives the information that client B had pressed a button.
The overall idea to have a page were client A can click a button "I'm ready to play" and starts waiting for client B's response. Client B receives a notification and presses a button "I'm ready too". Client A receives a notification telling Client B is ready too.
I know this could be done with AJAX. But I'm not really sure how to 'wait' for the client B response and update the webpage when the response arrive.
Any help / tip is welcome.
Thanks for your support.
Asynchronous
You seem to think in synchronous way, but that's not how you should think about this. You are issuing a command to the server, but you should not wait for the response, because:
the command might never arrive, for ex. due to Internet connectivity issues
the server might be down
the server might error out your command and never respond
the other player might never receive the message
the other player might never answer the message
the server might never receive the other player's command
the server might error out the other player's command
the server might never send you the notification
you might never receive the notification
So many point of possible failure on the one hand. And... Javascript is single-threaded on the other hand. So, if you wait for the other player to respond, then your UI will froze in the meantime (with the exception of Web Workers, but that's a more advanced topic, for now, let's view Javascript as a single-threaded environment)
Instead you should think asynchronously. In fact, in the achronim of AJAX, the first "A" stands for "Asynchronous". This means that you issue a request and define what you will do when a response is received. This "what will you do" is called the callback. Your client-side will work and be responsive in the meantime and when a response arrives it will know what to do.
Not only your request, but the other's response
Okay, now that we think asynchronously, we need to consider our options to handle when the other player decides to join your game:
Polling
You may issue periodic requests to the server via setTimeout and AJAX requests and once the response notifies you about the game being accepted, handle it accordingly. See: https://davidwalsh.name/javascript-polling
Push notifications
The server may send notifications to the users once an event occurs. See: https://onesignal.com/lp-web-push?utm_source=google&utm_medium=cpc&utm_campaign=general&gclid=CjwKCAjw4_H6BRALEiwAvgfzq9s03BR1OhlvxwN6SCn6Q_bIKODk3bQK05gwdaHTpwvzV2d7mXQU9hoCSl4QAvD_BwE
But you may want to use something that's compatible with what you are using at the server.
WebSockets
WebSockets are duplex channels, which are kept open. If the framework is implemented and supported, then client A and client B would both be connected, client A would send a command via WebSocket, the server would receive that and notify client B via WebSocket. When client B decides to accept the challenge, he would click on the button, which would issue a command of his own to the server via WebSocket and the server would notify client A via WebSocket. See: https://developer.mozilla.org/en-US/docs/Web/API/WebSocket
Summary
It's better to view this as a series of events and event handlers, rather than waiting for a response.

Listener in front end to listen on back end listener

I’ve been looking for an answer regarding this but can’t find anything good. I have a listener on cloudant which I have built in NodeJS. So when cloudant gets updated a function in my code gets called. My problem is that this data should be available as live data in a front end application. If I put the listener in an API-endpoint/middleware it won’t get called unless it gets a request from front end I guess?
So my question is: How can I create a listener in backend which can send data to front end whenever a change in cloudant appears? Basically I want a listener in front end to listen on a listener in back end.
So, what you're looking for is the ability to send or "push" data from server to client. The typical way of doing this is with a webSocket or socket.io connection. The client connects to the server and creates a lasting connection to the server. From then on, the server can just send data to the client over that connection whenever it wants to. The client then creates a listener on that connection so it will know when there is incoming data and it can then act accordingly based on the data.
webSocket is the standard built-into browsers that enables this type of function. socket.io is an additional client and server layer built on top of a webSocket connection that adds a lot of useful features such as auto-reconnection if the connection dies, a JSON message definition layer so you don't have to define your own data format, etc...
Here's how this would normally work:
When the server initializes, it creates a socket.io listener for incoming socket.io connections. webSocket/socket.io are built to "share" the same web server that you are using for loading web pages so you don't need an additional server or port.
When a page loads in the browser, some Javascript in that page creates a socket.io connection to the server.
The client then sets up listeners for whatever messages it wants to be able to act on.
Meanwhile, when the server gets something that it wants to send to the clients, it can either send that data to all currently connected clients or it can send it to only one specific client.
Then, the client's event listener will trigger and it will receive the data.
The client can then decide what it wants to do with the data, typically insert something in the current displayed page.
When the browser is changed to another web page, the socket.io connection will automatically be disconnected.
The socket.io documentation has several pieces of sample code for both client and server to show you how it is programmed.

Is it good - use setInterval for data refreshing?

I have an issue - I should update information for user as soon as possible, but i don't know exact time when it'll happen.
I use setInterval function that checks differences between current state and the state before checking. If there are any differences then I send an AJAX request and update info. Is it bad? I can't (or don't know how to) listen any events in that case.
And what about interval time? All users (~300 at the same time) are from local network (ping 15-20 ms). I have to refresh information immediately. Should I better use 50ms or 500ms?
If the question is not very clear just ask - I'll try to say it in other words.
Thanks in advance
Solution: Websocket
Websockets allow client applications to respond to messages initiated from the server (compare this with HTTP where the client needs to first ask the server for data via a request). A good solution would be to utilize a websocket library or framework. On the client you'll need to create a websocket connection with the server, and on the server you'll need to alert any open websockets whenever an update occurs.
The issue with interval
It doesn't scale, you could set the interval to 4000 miliseconds and still once you hit 1000 users...you are going to be slamming your server with 10000 requests and responses a minute...This will use tons of data and use processing to return nothing. Websockets will only send data to the client agent only when the event you want to send actually occurs.
Backend: PHP
Frameworks
Ratchet
Ratchet SourceCode
phpwebsocket
PHP-Websockets-Server
Simply implement one of the above frameworks as a websocket connection then you will register as a client to this endpoint and it will send data on whatever event you define.

Socket.io: disconnect, reconnect events etc

I am trying to get a handle on the various connection/disconnection events and how to use these to make sure that my application will always terminate gracefully.
I understand that socket.io will automatically attempt to reconnect a specified number of times. It is my understanding that as the connection goes down and subsequently reconnects there will be a disconnection event fired server side. I do not care about the connection temporarily going down so long as it comes back up at some point.
However if there is a more permanent disconnect, I do care about this and would need to update data such as connected users. I understand that on the client side you can get a reconnect_failed error object but I do not believe you can listen for this on the server. Is there any way to get notification on the server side that the connection is down and reconnection has failed? If so how does socket.io implement this?
I could issue a timeout upon a disconnection event server side that removes users if there is no reconnection. I could also have the server ping all connected clients at certain intervals. Are these kinds of solutions the only way to completely deal with all kinds of possible disconnections?

Event based Ajax communication between server and browser

I'm going to write an application, having some worker threads on the server, and some log and status elements on the html page. logs and status are expected to be updated whenever an update is ready from the server side.
well, one approach is to set up a polling mechanism, like the client sends a request on specified intervals and the server sends back the last update, (if any available).
however I wonder if there is any more efficient way like an interrupt-driven approach, on which whenever an update is ready on the server a message is sent to the client through an Ajax call. and as long as no update exists no message is transferred back and forth.
first of all, is this possible to initiate a call from the server side? I mean via Ajax.
or is there any library like JQuery that facilitates such a requirement?
Thanks
Consider using web sockets (Available in HTML5) - This will allow you to skip polling an update the data immediately as the server sends up his finish request.
Read more on:
http://www.html5rocks.com/en/tutorials/websockets/basics/

Categories