NodeJS & Socket.io: Chrome not loading with WebSockets
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 lates开发者_如何学运维t socket.io and nodejs v2.5
--
The first time I connect, it uses Websocket, but disconnects right away and reconnects with xhr-polling.
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
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.
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.
精彩评论