"websocket connection invalid" happens nondeterministically

[dominiek]

In both 0.7.9 and 0.8.4 this error seems to occur. I haven't been able to recreate the situation, because only some of my users have this problem (definitely happening on Chrome 14.0.835.186)

A temporary fix is to turn off websockets.

[frank06]

subscribing

[databyte]

subscribing as well

[saschagehlich]

+1

[3rd-Eden]

Would love to have moar information about this

Node version

Socket.io client & socket.io server version numbers (please confirm them by checking out your node_modules folder and checking out the package.json)

Platform, windows, mac etc & version
Is it reproducible or is it happening sometimes
are you behind a proxy, or using anti virus software on the machine where you are testing this.

[3rd-Eden]

@einaros any indication on why something like this would occur? (as you wrote the parsers :P)

[saschagehlich]

Actually it was my fault. Had socket.io-client 0.7.3 as a submodule - so i was at client 0.7.3, server 0.8.4. Fail. Removed the submodule, now everything works fine.

[3rd-Eden]

Well I'm glad you got it solved :)

On Sun, Sep 25, 2011 at 12:07 PM, Sascha Gehlich <
reply@reply.github.com>wrote:

Actually it was my fault. Had socket.io-client 0.7.3 as a submodule - so i
was at client 0.7.3, server 0.8.4. Fail. Removed the submodule, now
everything works fine.

Reply to this email directly or view it on GitHub:
#535 (comment)

[3rd-Eden]

@dominiek @frank06 @databyte could it be that you have simular issues?

[databyte]

Unfortunately I've encountered either machines or specific Internet connections that hate websockets whether via issues with firewalls or some undetermined local machine problem. We see an issue roughly 1 out of 150 clients.

Here are my two cases which left me with no choice but to disable websockets.

Case 1: Mac, Lion, Firefox 6.02, could not connect via websockets from work, home, or Internet cafe. Logs showed no connection.

Solution: disable websocket. Immediately connected once disabled. Have not determined what on that machine besides running a Cisco VPN Client would cause it to fail. I have not placed hands on the machine since it's a customer.

Case 2: Single user. Multiple computers (Mac and PC) and multiple new browsers (Fx 6 / Safari) - all websocket connected. Logs showed either two issues:

i, 9/22 20:18:12.847;  handshake authorized 69622656052978708
w, 9/22 20:18:12.959;  websocket connection invalid
i, 9/22 20:18:12.960;  transport end
i, 9/22 20:18:12.960;  [Connection] 69622656052978708: connected
w, 9/22 20:18:12.974;  websocket connection invalid
i, 9/22 20:18:12.974;  transport end
w, 9/22 20:18:12.999;  websocket connection invalid
i, 9/22 20:18:13.000;  transport end
i, 9/22 20:18:15.837;  transport end
i, 9/22 20:18:16.250;  handshake authorized 21026743801772718905

or

w, 9/23 14:24:11.761;  websocket parser error: continuation frame cannot follow current opcode
w, 9/23 14:36:36.274;  websocket parser error: continuation frame cannot follow current opcode
w, 9/23 14:45:18.181;  websocket parser error: continuation frame cannot follow current opcode
w, 9/23 14:52:57.615;  websocket parser error: continuation frame cannot follow current opcode

We tried for many (many) hours to reproduce the scenario in which either connection could be fouled but could only come up with setting up a proxy server that eats the upgrade notice. As we were building the proxy option, we also discovered disabling websockets as a workaround - so we haven't worked much on the issue since. Once we get past an end-of-month deadline, we'll look back into it.

Unlike @saschagehlich, Socket.io versions matched client and server, switched over to pulling client js directly from node - no change.

Lots of clients work just fine - tons - including our own. Something either proxy or locally causes the communication on websockets to fail. The ultimate solution would be for the protocol to fallback to another option even after the connection is established under websockets. Right now, it seems to just throw an error and the client stays disconnected or never connects at all.

And my team's more than willing to check deeper... next month... :-(

[dominiek]

I can also confirm that this is not a client and server version mismatch problem. Both versions are the same.

Server: Socket.io 0.7.9 / Node v0.4.10 / Ubuntu Linux
Client: Socket.io 0.7.9 / Firefox 4 / Chrome 14

(Also tried 0.8.4 on both client and server to no avail)

[3rd-Eden]

Socket.io 0.8 only has support for the latest websockets that ff 6.0 and chrome 14 are using so you should upgrade to the latest version anyways

~ Arnout Kazemier

On Sep 25, 2011, at 5:36 PM, Dominiek ter Heidereply@reply.github.com wrote:

I can also confirm that this is not a client and server version mismatch problem. Both versions are the same.

Server: Socket.io 0.7.9 / Node v0.4.10 / Ubuntu Linux
Client: Socket.io 0.7.9 / Firefox 4 / Chrome 14

(Also tried 0.8.4 on both client and server to no avail)

Reply to this email directly or view it on GitHub:
#535 (comment)

[databyte]

by upgrade, I mean:
https://github.com/LearnBoost/socket.io/blob/master/lib/transports/websocket/hybi-07-12.js#L78
and
https://github.com/LearnBoost/socket.io/blob/master/lib/transports/websocket/hybi-07-12.js#L100

[einaros]

@databyte, I noticed an issue which could have caused websocket continuation packets to fail with some websocket implementations.

Pending verification and incorporation into the main source tree, could you clone my repo (https://github.com/einaros/socket.io) and see if that at least improves the "continuation frame cannot follow current opcode" issue you reported?

[tjsingleton]

@einaros, @databyte is enjoying a vacation. I saw your pull request got merged and I deployed from git today.

[einaros]

@tjsingleton, the fixes I commented on above haven't been merged into the main tree yet. They are coming along with the hybi-16 parsers, though, which I'm opening a pull for now.