Socket.io: why does socket.io uses websocket connection and xhr polling parallel?

• "XHR polling" is not a connection, it could use more than one connection.
• The websocket and polling transports are not initialized concurrently, yet. In fact, that's what engine.io does and what socket.io will soon do once it implements it. Read more here and you might re-consider the "stupid" label, maybe.

If you're encountering a situation where socket.io 0.9 has two open transports concurrently, that would be a bug, and more information about how to reproduce it would be appreciated.

"XHR polling" is not a connection, it could use more than one connection.

Yep, but because the polling works on the same url all the requests. I assume it should emulate one.

If you're encountering a situation where socket.io 0.9 has two open transports concurrently, that would be a bug, and more information about how to reproduce it would be appreciated.

I am not sure if we mean the same but: Chromium shows me an open websocket connection and additionally it is sending polling requests to socket.io.
The "stupid" now means that I can't follow the benefit of a usable websocket connect and polling.
Shouldn't the websocket connection it self be sufficient and xhr polling only be used as fallback?

Correct me if I missed something

@bodokaiser did the websocket connection actually work or is it fallbacking to polling?

Keep in mind, the handshake is regular HTTP

Chrome Shows me that the websocket connection is pending. There is no error message. I assume that the ws works. Nevertheless how can I check if socket.io is falling back?

Yep, its definitely not the handshake. I see in chrome and in the node console how a get requests is getting repeated every 2000ms.

Would the node.js logging help you?

Regards

Inspect the frames that were exchanged in the ws connection (I think only Chrome has this). If you see no data, then it didn't work.

Yep seems to be fall backing:

  debug - client authorized
   info  - handshake authorized yUEmr7drZfmWzWHdEZcp
GET /socket.io/1/?t=1344799805756 200 3ms
   debug - setting request GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815866
   debug - setting poll timeout
   debug - client authorized for 
   debug - clearing poll timeout
   debug - xhr-polling writing 1::
   debug - set close timeout for client yUEmr7drZfmWzWHdEZcp
GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815866 200 1ms
   debug - xhr-polling received data packet 5:::{"name":"hello","args":["world"]}
POST /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815871 200 1ms
   debug - setting request GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815872
   debug - setting poll timeout
   debug - discarding transport
   debug - cleared close timeout for client yUEmr7drZfmWzWHdEZcp
   debug - clearing poll timeout
   debug - xhr-polling writing 8::
   debug - set close timeout for client T9eCOR7gCe3pLNtiEZco
   debug - xhr-polling closed due to exceeded duration
GET /socket.io/1/xhr-polling/T9eCOR7gCe3pLNtiEZco?t=1344799800945 200 20002ms
   debug - clearing poll timeout
   debug - xhr-polling writing 8::
   debug - set close timeout for client yUEmr7drZfmWzWHdEZcp
   debug - xhr-polling closed due to exceeded duration

@guille could you say me why it is fallbacking?

What browser are you using?

Chroms 21 for Mac OSX

I'm also seeing the same issue on Chrome 21/Windows 21.0.1180.79 m -- there is a JSONP polling connection (that seems successful) with a simultaneous WebSocket connection that never connects -- it's always in the "Pending" state. The same version of Chrome on Mac seems fine.

This does not seems firewall or antivirus-related, all tests pass on websocketstest.org and websocket.org/echo.html.

I'm using socket.io 0.9, but it also seems to be present in the latest version as well.

@guille This issue seems pretty easy to reproduce as well. I just visited a site that uses socket.io's WebSocket transport:

http://beta.blaggart.com

Note that, in Chrome 21 on Windows at least, the status of the WS connection is always "Pending."

Try with socket.io master ?

Just tried master and I have the same issue. Think this issue might also be a dupe of #998.

Also, for what it's worth, the workaround described in #998 did work for me in getting a connection to establish -- disabling websockets and only using xhr and jsonp polling.

is this actually a chrome bug?

when doing a test at www.websocket.org/echo.html

Funny thing is that when i use "secure WebSocket (TLS)" on that same website then websocket works.

exactly same behaviour for both Chrome and Firefox.. very weird..

Server:

socket.on('loginout',function(){
    socket.emit('loginout',{uname:socket.name});
});

socket.on('login',function(data){
socket.emit('l_msg',{uname:data.uname,score:data.score,type:true});
});

Print:
info: handshake authorized 11012331592122282453
debug: setting request GET /socket.io/1/xhr-polling/11012331592122282453?t=1353485202761
debug: setting poll timeout
debug: client authorized for
debug: clearing poll timeout
debug: xhr-polling writing 1::
debug: set close timeout for client 11012331592122282453
debug: xhr-polling received data packet �20�5:::{"name":"count"}�22�5:::{"name":"history"}�23�5:::{"name":"userList"}
debug: setting request GET /socket.io/1/xhr-polling/11012331592122282453?t=1353485202792
debug: setting poll timeout
debug: discarding transport
debug: cleared close timeout for client 11012331592122282453
debug: clearing poll timeout
debug: xhr-polling writing 8::
debug: set close timeout for client 1896586469607627233
debug: xhr-polling closed due to exceeded duration
debug: xhr-polling received data packet 5:::{"name":"login","args":[{"uname":"gjjn","pwd":"3f01728152a0225ff9806c401ffdbe77"}]}
debug: clearing poll timeout
debug: xhr-polling writing 5:::{"name":"l_msg","args":[{"uname":"gjjn","type":true,"head":"http://42.121.14.234/undefined"}]}
debug: set close timeout for client 11012331592122282453
debug: xhr-polling received data packet 5:::{"name":"loginout"}
debug: websocket writing 5:::{"name":"l_msg","args":[{"uname":"gregergre","type":true,"head":"http://42.121.14.234/undefined"}]}
debug: emitting heartbeat for client 5207531891749391108
debug: websocket writing 2::
debug: set heartbeat timeout for client 5207531891749391108
debug: got heartbeat packet
debug: cleared heartbeat timeout for client 5207531891749391108
debug: set heartbeat interval for client 5207531891749391108
debug: websocket writing 5:::{"name":"loginout","args":[{}]}

The xhr-polling received data packet 5:::{"name":"loginout"}.
But not Result.

The same here. I used the same code but it works on Chrome MacOS but not on Chrome Windows

how to reproduce - https://gist.github.com/jonnsl/5021596

+1, please fix this issue.. @LearnBoost

Even I'm seeing this, on my end I see as Websocket connection and a repeated XHR request sent to SOCKET.io server

Seem like a websocket connection resulted in success yet I see XHR request

Request URL:ws://localhost:5000/socket.io/?EIO=2&transport=websocket&sid=XcMblHoZ0x97QRn_AAAE
Request Method:GET
Status Code:101 Switching Protocols
Request Headers CAUTION: Provisional headers are shown.
Cache-Control:no-cache
Connection:Upgrade
Cookie:io=XcMblHoZ0x97QRn_AAAE
Host:localhost:5000
Origin:http://localhost:3000
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits, x-webkit-deflate-frame
Sec-WebSocket-Key:EZixwYoUHpFFpgrEOqiS+w==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Query String Parametersview sourceview URL encoded
EIO:2
transport:websocket
sid:XcMblHoZ0x97QRn_AAAE
Response Headers
Connection:Upgrade
Sec-WebSocket-Accept:WHsiBZoW9stmULt+YX8wmNK1wx8=
Upgrade:websocket

Here how the websocket frames look like
https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

And the Long Polling Request

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot%202014-07-09%2011.15.47.png

I'm Running on Google Chrome 35.0.1916.153

and the socket issue version is [email protected]

I have the same issue. Any updates? Using SocketIO 1.0.6

The first request is always XHR, then we _upgrade_ to WebSocket (if we can). Subsequent polling is aborted (there might be an extra polling cycle in some cases, but never more than 1)

@guille as for what I checked I see a repeat XHR polling even if the Websocket connection was established successfully

Hi,

What's the solution to resolve this issue ?

@rohittailor : I'm testing this on the client:

    <script src="/socket.io/socket.io.js"></script>
    <script>
        var socket = io.connect({transports: ['websocket']});
    </script>

and so far so good. It's completely avoiding the XHR connection.

This solve my issue as well, websocket was working fine BUT there was also a dirty XHR polling. Thanks @gonzalodiaz

I'd really like to see a scenario where it upgrades to WS successfully but XHR polling cycles continue indefinitely in Web Inspector!

(a demo, video, animated gif, anything works)

I can give you a demo access to my web site, hosted on MS Azure cloud tomorrow. Can you give us your test URL and more details about how socket.io is hosted?

@guille How about this

Here how the websocket frames look like
https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

And the Long Polling Request

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot%202014-07-09%2011.15.47.png

Do those keep going indefinitely? Are there duplicate frames in the
responses? Could you post the corresponding server log with DEBUG=* and the
browser log with localStorage.debug='*' when this situation happens?

—
Guillermo Rauch – @rauchg https://twitter.com/rauchg

On Tue, Oct 14, 2014 at 10:59 PM, Viren Negi [email protected]
wrote:

@guille https://github.com/guille How about this

Here how the websocket frames look like

https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

And the Long Polling Request

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot%202014-07-09%2011.15.47.png

—
Reply to this email directly or view it on GitHub
https://github.com/Automattic/socket.io/issues/991#issuecomment-59161273
.

@guille I do see the xhr response repeat indefinitely not sure about duplicate frame let me see If I can provide all that you need

Not sure how helpful I can be, but I'm noticing that I can only connect to a web socket if it's secure. Have there been some recent security changes that require a header (CORS like) to allow unsecure WebSocket connections?

WebSockets worked a month ago for me, now it only works for wss:// connections.
Chrome 38.0.2125.104 - Windows 8.1.1

Edit: These results might actually be an issue with http://www.websocket.org/echo.html
I've been unable to test elsewhere

The success of the WS connection really depends on network / server capabilities. SSL guarantees nothing can break it before the data is decrypted (subsequent proxies / load balancers can still break it though).

I noticed that it was actually a bug in the code, it never even polled the WS connection, I made a change and then it worked. If I remember I'll look at the modified source tonight.

But if it's working for everyone else it could be something else that is wrong with my setup, but it wasn't trying to connect because it thought that WS was unavailable without trying, changing a && to a || fixed it.

I'd like to hear more!

Still a (small) issue, the client always makes poll requests instead of try another transports. I have to specify

{transports: ['websocket']}

To get it working, but the client should try all transports to find the good one, right?

This issue was the reason why I started back in 2012/13 to work on an own "pure" web socket package.

Has this issue been solved? I'm seeing something similar, but before I start digging deep I wanted to do a quick search... comments?

The code has changed a fair bit since I last commented on this issue. It's unlikely it's the same bug. I can't seem to find the line that I suspected was causing the issue last time. That's not to say it's fixed.

My socket.io code is currently blocked by a bug engine.io-client so I've not used s.io for a few months now so can't say for certain if this is still an issue.

@nevercast your comment about wss working but ws not was totally right in my case. Thanks for pointing it out I've been searching for this issue for over a week. Found that somehow any ws connection on my network was being blocked but wss worked fine.

This website is great: http://websocketstest.com/ it tells you which ports are able to run websockets on any given network. Recommend checking this before getting too involved in websocket debugging.

i have an issue with socket io but not sure where i am wrong.

the above image show that it works fine in local but the below image is captured while attempting in AWS environment.

i have an issue with socket io but not sure where i am wrong.

the above image show that it works fine in local but the below image is captured while attempting in AWS environment.

facing same problem