-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"websocket connection invalid" happens nondeterministically #535
Comments
subscribing |
subscribing as well |
+1 |
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 |
@einaros any indication on why something like this would occur? (as you wrote the parsers :P) |
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. |
Well I'm glad you got it solved :) On Sun, Sep 25, 2011 at 12:07 PM, Sascha Gehlich <
|
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:
or
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... :-( |
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 (Also tried 0.8.4 on both client and server to no avail) |
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:
|
@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, 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. |
This has been merged in 0.8.5, if this same issue still occurs feel free to poke me so i can reopen it. |
That change will allow to retrieve the client id asynchronously, from a database for example.
That is a breaking change, which mandates a major bump.
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.
The text was updated successfully, but these errors were encountered: