3

Chrome is loading with long polling, and the loading indicator doesn't stop.

Why is Chrome not using WebSockets, and how can I prevent the loading indicator from spinning when it does use long polling?

I'm using the latest socket.io and nodejs v2.5

--

The first time I connect, it uses Websocket, but disconnects right away and reconnects with xhr-polling.

Luke Burns
  • 1,911
  • 3
  • 24
  • 30

3 Answers3

3

I had a similar problem and I found that there was a socketio cookie overriding the transport method to "xhr-polling". I don't know how the cookie got there, but deleting it did the trick.

Here's a reference to the line that looks for the cookie. https://github.com/LearnBoost/Socket.IO/blob/master/socket.io.js#L1023

mbrevoort
  • 5,075
  • 6
  • 38
  • 48
  • I found the cookie, deleted it, and it fixed this problem for me. Thanks! – Eric Naeseth Dec 29 '10 at 05:44
  • deleting the cookie solved the problem and also my long awaited question as to why the hell websocket never worked even in my latest chrome 30. Thanks a lot for this answer. +1 – Anmol Saraf Oct 30 '13 at 10:48
2

It appears that socket.io.js has options that control this.

  • tryTransportsOnConnectTimeout - default value is true
  • rememberTransport - default value is true

I believe that if 'tryTransportsOnConnectTimeout' is set to 'true' then socket.io will iterate through all transport mechanisms on connect and use the first one that succeeds.

If 'rememberTransport' is set to 'true' the transport that was successful is stored in a cookie.

In my application I implemented logic to re-connect when disconnected. I found that I had to set both of the above options to 'false' to prevent falling back to a undesired transport. The issue occurred because after disconnect, the server might become available at any point (while the client was attempting long-poll rather than websockets for example). If that occurred, the cookie was set and subsequent connections would continue to use the undesired transport.

Jon Nalley
  • 511
  • 2
  • 8
0

I'm using Chrome 8 and WebSockets appear to work fine.

If you're using socket.io, it should fall back to FlashSockets or even xhr-multipart before long polling (or forever iframe). Check your transport options when initialising socket.io on both the server and the client.

Robin Duckett
  • 2,094
  • 3
  • 16
  • 15
  • I'm using two different subdomains on webfaction-- The only thing I can think of is that it's falling back to polling because it thinks its cross-domain? Probably something to do with webfaction. – Luke Burns Dec 15 '10 at 18:31
  • Try setting the transports to force a specific transport which isn't polling. – Robin Duckett Dec 16 '10 at 14:04
  • I tried setting it in the options on client-side, and it still connected with xhr-polling. Is there a way to force it on the server? – Luke Burns Dec 16 '10 at 23:09