NodeJS & Socket.io: Chrome does not load using WebSockets

Question

Chrome loads a long poll, and the download indicator does not stop.

Why doesn't Chrome use WebSockets, and how can I prevent the download indicator from turning when it uses a long poll?

I use the latest socket.io and nodejs v2.5

-

The first time it connects, it uses Websocket, but immediately disconnects and reconnects with xhr polling.

Answer 1

I had a similar problem and found that the socketio cookie overrides the transport method to "xhr-poll". I don’t know how the cookie got there, but removing it did the trick.

Here is the link to the line that is looking for the cookie. https://github.com/LearnBoost/Socket.IO/blob/master/socket.io.js#L1023

Answer 2

It looks like socket.io.js has parameters that control this.

• tryTransportsOnConnectTimeout - default value - true
• Transport - default value - true

I believe that if the tryTransportsOnConnectTimeout parameter is set to "true", then socket.io will iterate over all transport mechanisms when connected and use the first one that will succeed.

If the Remember Transport option is set to true, the successful transport is stored in a cookie.

In my application, I implemented logic to reconnect when disconnected. I found that I needed to set both parameters above "false" to prevent a return to unwanted transmission. The problem arose because after disconnecting the server can become available at any time (while the client, for example, tried to use polls rather than websites). If this happened, a cookie was set and subsequent connections continued to use unwanted transport.

Answer 3

I am using Chrome 8 and WebSockets are working fine.

If you use socket.io, it should return to FlashSocket or even to xhr-multipart before a long poll (or forever iframe). Check the transport settings when initializing socket.io both on the server and on the client.