Different between socket.io and sockjs in Connection quality

[Kamil Krzyszczuk]

In socket.io 0.9.x if you scale your app with clusters module, you probably very often will get "client not handshaken client should reconnect"

There is a fix that it doesn't spam your log but problem still exists. I add socket.on('reconnect"); to inform server when client reconnected and which transport is used. And now in log I have  really a lot of reconnect informations. This is terrible and make increasing of CPU usage, so u have to restart your app often. That's why I decided to switch to SockJS. But now I have a question according to this story.

How often I will get reconnect notice in SockJS? I know there isn't a native reconnect mechanism, but I built one this way:

if onclose, then sockjs = new connection;

but then I lost session_id because it gets new one. So I wonder how often reconnect happen in big applications. Because if it happens often in SockJS then I will have to switch back to Socket.io because even if socket.io reconnect, session_id isn't lost.

Maybe someone who handle big traffic can reply this topic?

[Vladimir Dronnikov]

Quote from sockjs-protocol:

....

... session_id must be a random string, unique for every session.

It is undefined what happens when two clients share the samesession_id. It is a client responsibility to choose identifier with enough entropy.

Neither server nor client API's can expose session_id to the application. This field must be protected from the app.

....

[Marek Majkowski]

On Wed, Jan 9, 2013 at 1:23 PM, Kamil Krzyszczuk
<krzyszc...@gmail.com> wrote:
> How often I will get reconnect notice in SockJS? I know there isn't a native
> reconnect mechanism, but I built one this way:
> if onclose, then sockjs = new connection;

Beware with that. You can easily DDOS your server when you'll have
a network hiccup or if you'll restart your server.

Better way is to introduce a timer and an exponential backoff mechanism.
(on the client side)

> but then I lost session_id because it gets new one. So I wonder how often
> reconnect happen in big applications. Because if it happens often in SockJS
> then I will have to switch back to Socket.io because even if socket.io
> reconnect, session_id isn't lost.
>
> Maybe someone who handle big traffic can reply this topic?

Lack of built-in reconnection mechanism and not reusing session_id is
deliberate.

You need to build the reconnection and re-synchronization mechanisms
in your application. This is your responsibility.

SockJS gives you a tcp/ip like layer - a connection. If a connection is
broken, for any reason, it's the application that needs to understand that
and react accordingly.

If you have some state connected to the session (username,
last-delivered-message number, etc) - you need to pass that
information to the new session. But all that stuff is very application
specific and SockJS can't help you with it.

Marek

[Carl Byström]

On Wed, Jan 9, 2013 at 3:24 PM, Marek Majkowski <maj...@gmail.com> wrote:

Better way is to introduce a timer and an exponential backoff mechanism.

(on the client side)

Also consider randomizing the backoff delays by a given percentage (+/- 30%).

[Kamil Krzyszczuk]

But what If i have something more connected to session than some vars? Because every session has connection to another user by holding Stranger_id that is var too ya, and I can pass it to new session but, onclose event tells my stranger that I'm out, so chat can be done, but if onclose was fired because of unpluged Internet, then chat can't be done. How to know difference in server script? Server needs to decide to: keep chat alive because user is about to reconnect or not keep chat, because user is really out of app.

[Fugiman]

To answer your original question: With a stable internet connection, I've maintained a SockJS session for over a week while sending a few MB a day through it.

In terms of reconnection: I can not stress enough that you shouldn't be trying to handle network failures and intentional closing of the app differently. In the event of a network failure, you do not know if the client is coming back in a reasonable time. Does their partner just sit there alone until they return? What if their partner leaves while they are disconnected? Will your state storage fill up if people lose network connection too often? Won't it connect as a new user anyway if they refresh while their network is down?

When onclose fires, the client is gone and may never come back. You shouldn't expect them to return. You can program the client to reconnect (I did too), but establish a new, fresh session.

[Kamil Krzyszczuk]

When I reconnected and have my old stranger_id I can check if there still is connection that have session = my stranger_id.

[Kamil Krzyszczuk]

Over a week? And there were not any reconnections? That is a great news. :)

W dniu środa, 9 stycznia 2013 21:07:34 UTC+1 użytkownik Fugiman napisał: