7

I've been looking around to implement a reliable WebSocket connection recovery mechanism.

After some investigation, I've found that one way is sending hearbeats to the server (ping/pong), and check if I receive the whole pong in a limited time.

Thus, either if the connection is actually down or it's very slow it would be considered disconnected if a pong wait timeouts, and code should call WebSocket.close().

At the end of the day, I'm asking this question to validate the connection-reconnection workflow using WebSockets, and check if I'm missing something.

That is, my question is, is this the right and reliable workflow to implement WebSockets reconnection mechanism?

Improve this question

1 Answer 1

Reset to default
4

The websocket protocol define special control frames for ping and pong, but they are not accessible through the JavaScript API. But if the server send those frames, the browser will answer.

However, if the connection is cut suddenly and become an half-open connection, although the server will detect it, the browser won't. So I guess that sending your own pings at application level is not a bad idea.

Answering your question yes, it is good idea because if the connection gets half opened, your client is not getting updates because he thinks it is connected. In websocket, the client has to initiate the connection, so even if the browser realizes the disconnection, there is nothing it can do to reconnect.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

Yes, you're right (and thanks for your "confirmation"). BTW, there's the mobile use case, where sending pings every 20 seconds (for example) has an impact on battery. In my case, since I'm not using WebSockets for user input, but for server pushes, I want to notice the user that the connection has issues as soon as possible.
You can detect the network latency by sending a ping with a timestamp and making the server echoing it in the pong. But if the communication is cut (ie: without proper TCP termination) it is hard to say it is cut till you try to send something: blog.stephencleary.com/2009/05/…
@vtrola This is a very interesting article (why don't you add it to your answer as a reference?). BTW, I'm not sure if I understand the first solution of Correct Methods to Detect Dropped Connections. I understand that it's about sending an empty message (a keepalive message), and wait for a limited time, and if no response is received in some time, the connection is considered to be lost.
As far I understand, means that you send a keepalive message each X time, and if the server does not get a such message for you in a period of time, the server will cut the connection. At the same time, if the client fails to send the message, the client can consider the connection cut. I added the link to the answer.
But if we need to define client fails to send the message, we need to say "it didn't send the message in a limited time interval*. Am I wrong?

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.