I have a webapp, which is running in a browser. That webapp is connected to a server, which uses websockets. So the communication between the server and my client/browser is based on websockets. If some magic event occurs on the server, some webservice sends a new XML / JSON to my webapp and the new data gets displayed.
But how do i, as the client / browser, know if the connection is stil alive? Lets say i do not get any new XML for about 30 seconds. How would i know if the connection is closed/broken/server offline or everything is fine, but on the server himself no new magic event occured.
A websocket connection object has a readyState field which will tell you if the connection is still active (from the dart documentation). The readyState can be either
0 - connection not yet established
1 - conncetion established
2 - in closing handshake
3 - connection closed or could not open
You can also define an event handler for the websocket close event if this is something you'd like to handle (try to reconnect, etc).
3 ways:
rely on TCP to detect loss of connectivity, which will ultimately pop up in JS onclose event
send WebSocket pings from server .. browsers will reply with WS pongs, loss of connectivity is probably more robustly detected also on client side
send app level heartbeats from browser to server, server need to have logic to reply. you can't trigger WS pings from browsers (in JS)
Related
I start the server and the clients.
Then I close the server, and after few minutes reopen it.
I get too many messages (from the client).
How do I reset it, to start clean.
The server code:
var io = require('socket.io').listen(3001);
var games=[];
console.log('start1 server.js');
setTimeout(clear_games,30000);
io.sockets.on('connection', function(socket)
{
When your active socket.io clients lose the connection to the server, they will constantly try to reconnect until your server comes back online and they successfully get a reconnection. This is the normal and expected behavior and is generally a very useful features since the client will then automatically restablish a connect after a temporary server restart or interrupted network connection.
If you just want to start over for testing purposes, then close all the client web pages, shut down your server, then restart your server, then open the client web pages again. Because the client web pages will not be open when you start your server, it should not immediately get a bunch of reconnects.
If you never want the client to automatically reconnect, then you can specify that in an option in the client code that connects to the server with an option of {reconnection: false}, (though that is generally a bad idea because now the client won't auto-recover if the connection is temporarily interrupted).
What I did is:
In the client, I added a monitor function that is invoked (setTimeout) every second, and checks the socket.connected.
If it is not connected, I don't send any messages to the server till I see that it is true (connected) again.
This solved the problem.
I'm using uwsgi's websockets support and so far it's looking great, the server detects when the client disconnects and the client as well when the server goes down. But i'm concerned this will not work in every case/browser.
In other frameworks, namely sockjs, the connection is monitored by sending regular messages that work as heartbeats/pings. But uwsgi sends PING/PONG frames (ie. not regular messages/control frames) according to the websockets spec and so from the client side i have no way to know when the last ping was received from the server. So my question is this:
If the connection is dropped or blocked by some proxy will browsers reliably (ie. Chrome, IE, Firefox, Opera) detect no PING was received from the server and signal the connection as down or should i implement some additional ping/pong system so that the connection is detected as closed from the client side?
Thanks
You are totally right. There is no way from client side to track or send ping/pongs. So if the connection drops, the server is able of detecting this condition through the ping/pong, but the client is let hung... until it tries to send something and the underlying TCP mechanism detect that the other side is not ACKnowledging its packets.
Therefore, if the client application expects to be "listening" most of the time, it may be convenient to implement a keep alive system that works "both ways" as Stephen Clearly explains in the link you posted. But, this keep alive system would be part of your application layer, rather than part of the transport layer as ping/pongs.
For example you can have a message "{token:'whatever'}" that the server and client just echoes with a 5 seconds delay. The client should have a timer with a 10 seconds timeout that stops every time that messages is received and starts every time the message is echoed, if the timer triggers, the connection can be consider dropped.
Although browsers that implement the same RFC as uWSGI should detect reliably when the server closes the connection cleanly they won't detect when the connection is interrupted midway (half open connections)t. So from what i understand we should employ an extra mechanism like application level pings.
I'm currently exploring SignalR, this technology supports transports (web wockets, long polling ,server-sent events and forever frame).
I have understood the terminology web sockets and long polling. But what is Server-Sent Events and Forever Frame?
How all four differ from each other?
Transports and fallbacks of SignalR:
WebSocket Full-duplex
Websocket is a full-duplex communication channels over a single TCP connection. When both server and browser support, it is the only transport that establishes a true persistent, two-way connection between client and server.
Server Sent Events Simplex
also known as EventSource is a technology where a browser receives automatic updates from a server via HTTP connection. The Server-Sent Events EventSource API is standardized as part of HTML5 by the W3C.
Forever Frame One request -> One infinite response
Forever Frame creates a hidden IFrame which makes a request to an endpoint on the server that does not complete. The server then continually sends script to the client which is immediately executed, providing a one-way realtime connection from server to client. The connection from client to server uses a separate connection from the server to client connection, and like a standard HTTP request, a new connection is created for each piece of data that needs to be sent.
Ajax long polling (One Request -> One Response [but delayed]) repeated
Long polling does not create a persistent connection, but instead polls the server with a request that stays open until the server responds, at which point the connection closes, and a new connection is requested immediately. This may introduce some latency while the connection resets.
More info:
https://learn.microsoft.com/en-us/aspnet/signalr/overview/getting-started/introduction-to-signalr
https://en.wikipedia.org/wiki/Server-sent_events
Case:
A WebSocket connection have been established between the client and server endpoint.
Now I have the network connection go down (for example the ADSL dies), after 10 min I recover the network, I find that the client and server are still able to communicate with each
other. Why?
Note:
The client was developed with Java-WebSocket framework, and the client did with ws4py.
1 - If they did not try to exchange any data and only the connection (not the endpoints) between them is down, this is normal behaviour.
2 - If the websocket connection ended, Browser may have re-established it without you knowing about it. I just checked that this is not normal behaviour. But maybe there is some parameter somewhere :-)
If I am not wrong, to have a push technology the client ( say browser ) also needs to run a small web server which is listening on some port ( say ijetty runs on 8080 ). Now when the actual server comes to know about any event, it sends the event to client. This way there is no PULL mechanism involved at all. Is this right ? OR there is a persistent connection involved and server sends the data on that connection whenever the event happens. My question is : in the former case ( if it is true ), how does server know about client's IP ?
WebSockets working with socket based on TCP connection, basically the client make a request for connection to the server with a challenge, websocket version, ip and more data, then the server decrypts the challenge and return his result back to the client, this process called Handshake.
If the handshake is approved, the connection is made, the socket connection remains open between the client and the server, heartbeats will be sent from the server to the client like a ping to check if the connection is still open.
read this wiki to find out more:
http://en.wikipedia.org/wiki/WebSocket