hybi10 incompatibility

[ronkorving]

Please note that the latest dev Chrome has a newer version of the websocket protocol, which is incompatible with the current one.
For more info: http://googlechromereleases.blogspot.com/2011/07/chrome-dev-channel-release.html

[3rd-Eden]

We are aware of the issue, and @guille is working on new WebSocket parsers to supported the latest protocols (hopefully before they become stable)

[Fauntleroy]

Any news on this issue? It's really thrown a wrench into my dev environment...

[hedin-hiervard]

Well, the problem is even wider. Newest dev build of chrome doesn't even rollback to any transport and just silently fails. If you need a socket.io log of the serverside, just tell.

[3rd-Eden]

It fall backs perfectly here, It take a while, but it does fallback. (to http-polling)
On Aug 5, 2011, at 8:32 PM, Hedinhiervard wrote:

Well, the problem is even wider. Newest dev build of chrome doesn't even rollback to any transport and just silently fails. If you need a socket.io log of the serverside, just tell.

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

[Fauntleroy]

How long does it take? What's your fallback configuration like?

On Fri, Aug 5, 2011 at 11:57 AM, 3rd-Eden
reply@reply.github.com
wrote:

It fall backs perfectly here, It take a while, but it does fallback. (to http-polling)
On Aug 5, 2011, at 8:32 PM, Hedinhiervard wrote:

Well, the problem is even wider. Newest dev build of chrome doesn't even rollback to any transport and just silently fails. If you need a socket.io log of the serverside, just tell.

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

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

[hedin-hiervard]

It's plain default and it takes around 5 secs while it tries xhr and long polling. After that it reports connection but no data is being transmitted.

[3rd-Eden]

My current setup is at https://gist.github.com/1128254
It waits until the connect_timeout is called on the client side before it tries xhr polling so thats about 10 seconds

On Aug 5, 2011, at 9:03 PM, Fauntleroy wrote:

How long does it take? What's your fallback configuration like?

On Fri, Aug 5, 2011 at 11:57 AM, 3rd-Eden
reply@reply.github.com
wrote:

It fall backs perfectly here, It take a while, but it does fallback. (to http-polling)
On Aug 5, 2011, at 8:32 PM, Hedinhiervard wrote:

Well, the problem is even wider. Newest dev build of chrome doesn't even rollback to any transport and just silently fails. If you need a socket.io log of the serverside, just tell.

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

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

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

[hedin-hiervard]

Actually, that's what happens:

info - socket.io started
debug - served static /socket.io.js
debug - client authorized
info - handshake authorized 26546433926600702
debug - setting request GET /socket.io/1/websocket/26546433926600702
debug - set heartbeat interval for client 26546433926600702
warn - websocket connection invalid
info - transport end
debug - set close timeout for client 26546433926600702
debug - cleared close timeout for client 26546433926600702
debug - cleared heartbeat interval for client 26546433926600702
debug - client authorized for
debug - setting request GET /socket.io/1/xhr-polling/26546433926600702?t1312571445400
debug - setting poll timeout
debug - clearing poll timeout
debug - xhr-polling writing 1::
debug - set close timeout for client 26546433926600702
debug - setting request GET /socket.io/1/xhr-polling/26546433926600702?t1312571445411
debug - setting poll timeout
debug - discarding transport
debug - cleared close timeout for client 26546433926600702
debug - xhr-polling received data packet 3:::fsdf
debug - clearing poll timeout
debug - xhr-polling writing 3:::Неверная команда...
debug - set close timeout for client 26546433926600702
debug - setting request GET /socket.io/1/xhr-polling/26546433926600702?t1312571449625
debug - setting poll timeout
debug - discarding transport
debug - cleared close timeout for client 26546433926600702
debug - xhr-polling received data packet 3:::fsdf
debug - clearing poll timeout
debug - xhr-polling writing 3:::Неверная команда...
debug - set close timeout for client 26546433926600702
debug - setting request GET /socket.io/1/xhr-polling/26546433926600702?t1312571450683
debug - setting poll timeout
debug - discarding transport
debug - cleared close timeout for client 26546433926600702
debug - clearing poll timeout
info - transport end
debug - set close timeout for client 26546433926600702
debug - cleared close timeout for client 26546433926600702
debug - discarding transport
debug - client authorized
info - handshake authorized 202165488841588529
debug - setting request GET /socket.io/1/websocket/202165488841588529
debug - set heartbeat interval for client 202165488841588529
warn - websocket connection invalid
info - transport end
debug - set close timeout for client 202165488841588529
debug - cleared close timeout for client 202165488841588529
debug - cleared heartbeat interval for client 202165488841588529
debug - client authorized for
debug - client authorized
info - handshake authorized 16851469841649338061
debug - setting request GET /socket.io/1/websocket/16851469841649338061
debug - set heartbeat interval for client 16851469841649338061
warn - websocket connection invalid
info - transport end
debug - set close timeout for client 16851469841649338061
debug - cleared close timeout for client 16851469841649338061
debug - cleared heartbeat interval for client 16851469841649338061
debug - client authorized for
debug - client authorized
info - handshake authorized 1615724500500893364
debug - setting request GET /socket.io/1/websocket/1615724500500893364
debug - set heartbeat interval for client 1615724500500893364
warn - websocket connection invalid
info - transport end
debug - set close timeout for client 1615724500500893364
debug - cleared close timeout for client 1615724500500893364
debug - cleared heartbeat interval for client 1615724500500893364
debug - client authorized for
debug - client authorized
info - handshake authorized 1087226233792369978
debug - setting request GET /socket.io/1/websocket/1087226233792369978
debug - set heartbeat interval for client 1087226233792369978
warn - websocket connection invalid
info - transport end
debug - set close timeout for client 1087226233792369978
debug - cleared close timeout for client 1087226233792369978
debug - cleared heartbeat interval for client 1087226233792369978
debug - client authorized for
debug - client authorized
info - handshake authorized 1073278661102827052
debug - setting request GET /socket.io/1/websocket/1073278661102827052
debug - set heartbeat interval for client 1073278661102827052
warn - websocket connection invalid
info - transport end
debug - set close timeout for client 1073278661102827052
debug - cleared close timeout for client 1073278661102827052
debug - cleared heartbeat interval for client 1073278661102827052
debug - client authorized for

It connects via xhr, gets 3 or 4 mutual exchanges and loses connection permanently.

[mraleph]

@3rd-Eden here is what I get with you testcase on Chrome 14.0.835.8

LOG: Trying to connect using websocket
LOG: Trying to connect using xhr-polling
LOG: CONNECT EVENT CALLED
LOG: Aww, disconnected
LOG: reconnecting, attempt #1
LOG: Trying to connect using websocket
LOG: reconnecting, attempt #2
LOG: Trying to connect using websocket
LOG: reconnecting, attempt #3
LOG: Trying to connect using websocket
LOG: reconnecting, attempt #4
LOG: Trying to connect using websocket
LOG: reconnecting, attempt #5
LOG: Trying to connect using websocket
LOG: reconnecting, attempt #6
LOG: Trying to connect using websocket

Server side:

% node server.js                                       
   info  - socket.io started
   debug - served static /socket.io.js
   debug - client authorized
   info  - handshake authorized 2079936828185582961
   debug - setting request GET /socket.io/1/websocket/2079936828185582961
   debug - set heartbeat interval for client 2079936828185582961
   warn  - websocket connection invalid
   info  - transport end
   debug - set close timeout for client 2079936828185582961
   debug - cleared close timeout for client 2079936828185582961
   debug - cleared heartbeat interval for client 2079936828185582961
   debug - client authorized for 
   debug - setting request GET /socket.io/1/xhr-polling/2079936828185582961?t1312640367534
   debug - setting poll timeout
   debug - clearing poll timeout
   debug - xhr-polling writing 1::
   debug - set close timeout for client 2079936828185582961
   debug - xhr-polling received data packet 5:::{"name":"print","args":["foo"]}
has message foo
   debug - setting request GET /socket.io/1/xhr-polling/2079936828185582961?t1312640367541
   debug - setting poll timeout
   debug - discarding transport
   debug - cleared close timeout for client 2079936828185582961
   debug - xhr-polling received data packet 5:::{"name":"print","args":["bar"]}
has message bar
   debug - clearing poll timeout
   debug - xhr-polling writing 5:::{"name":"done"}
   debug - set close timeout for client 2079936828185582961
   debug - setting request GET /socket.io/1/xhr-polling/2079936828185582961?t1312640367554
   debug - setting poll timeout
   debug - discarding transport
   debug - cleared close timeout for client 2079936828185582961
   debug - clearing poll timeout
   info  - transport end
   debug - set close timeout for client 2079936828185582961
   debug - cleared close timeout for client 2079936828185582961
   debug - discarding transport
   debug - client authorized
   info  - handshake authorized 196735904715927054
   debug - setting request GET /socket.io/1/websocket/196735904715927054
   debug - set heartbeat interval for client 196735904715927054
   warn  - websocket connection invalid
   info  - transport end
   debug - set close timeout for client 196735904715927054
   debug - cleared close timeout for client 196735904715927054
   debug - cleared heartbeat interval for client 196735904715927054
   debug - client authorized for 
   debug - client authorized
   info  - handshake authorized 17394595521585406230
   debug - setting request GET /socket.io/1/websocket/17394595521585406230
   debug - set heartbeat interval for client 17394595521585406230
   warn  - websocket connection invalid
   info  - transport end
   debug - set close timeout for client 17394595521585406230
   debug - cleared close timeout for client 17394595521585406230
   debug - cleared heartbeat interval for client 17394595521585406230
   debug - client authorized for 
   debug - client authorized
   info  - handshake authorized 2113706619298164021
   debug - setting request GET /socket.io/1/websocket/2113706619298164021
   debug - set heartbeat interval for client 2113706619298164021
   warn  - websocket connection invalid
   info  - transport end
   debug - set close timeout for client 2113706619298164021
   debug - cleared close timeout for client 2113706619298164021
   debug - cleared heartbeat interval for client 2113706619298164021
   debug - client authorized for 
   debug - client authorized
   info  - handshake authorized 7325051861284717910
   debug - setting request GET /socket.io/1/websocket/7325051861284717910
   debug - set heartbeat interval for client 7325051861284717910
   warn  - websocket connection invalid
   info  - transport end
   debug - set close timeout for client 7325051861284717910
   debug - cleared close timeout for client 7325051861284717910
   debug - cleared heartbeat interval for client 7325051861284717910
   debug - client authorized for 
   debug - client authorized
   info  - handshake authorized 969090863992108901
   debug - setting request GET /socket.io/1/websocket/969090863992108901
   debug - set heartbeat interval for client 969090863992108901
   warn  - websocket connection invalid
   info  - transport end
   debug - set close timeout for client 969090863992108901
   debug - cleared close timeout for client 969090863992108901
   debug - cleared heartbeat interval for client 969090863992108901
   debug - client authorized for 
   debug - client authorized
   info  - handshake authorized 20578278151276642755
   debug - setting request GET /socket.io/1/websocket/20578278151276642755
   debug - set heartbeat interval for client 20578278151276642755
   warn  - websocket connection invalid
   info  - transport end
   debug - set close timeout for client 20578278151276642755
   debug - cleared close timeout for client 20578278151276642755
   debug - cleared heartbeat interval for client 20578278151276642755
   debug - client authorized for

If I am reading these logs correctly socket.io correctly fallbacks to xhr-polling but then looses (or closes) connection for some reason and does not handle reconnection correctly i.e. does not fallback to other transports when trying to reconnect always preferring websocket transport to others.

[3rd-Eden]

@mraleph

Yeah I noticed the same thing. The whole reconnect is currently being refactored and it will not be ready yet for atleast another week.

I think the reconnect with xhr is failing because it's not sending or receiving heart beat signals

debug - set close timeout for client 2079936828185582961
   debug - setting request GET /socket.io/1/xhr-polling/2079936828185582961?t1312640367554
   debug - setting poll timeout
   debug - discarding transport
   debug - cleared close timeout for client 2079936828185582961
   debug - clearing poll timeout
   info  - transport end

During that period I would have expected at least one heart beat message, so I guess to tackle this issue we need to

1. Have @guille finish support for the hybi 10 WebSocket specification
2. Track down the missing heart beat.

[perezd]

Are there plants to backport this fix to 0.6? Having issues on Chrome 14.0.835

[bdickason]

Just to escalate this issue, Chrome stable is now having the same problem. I (unfortunately) updated to latest and it's falling back to polling.

[scanferla]

Same problem here.
Chrome (14.0.835.35 beta-m) + Windows 7 takes about 30 seconds to connect (if it connects) and after connecting it's too slow to be usable.
Most of the time it even disconnects after a while.

Safari + Windows 7 and Chrome (13.0.782.112) + Ubuntu 10.04 are super fast and stable and I'm not having any problems with Firefox too.

I'm Running Socket.io with Nowjs on Nodester.

When I was running on Heroku (which doesn't have WebSockets) Chrome + Windows 7 always falling back to polling after waiting almost one minute and crashing a couple seconds later.

[rauchg]

Hiby support is gonna land next.

On Sat, Aug 13, 2011 at 8:25 AM, scanferla <
reply@reply.github.com>wrote:

Same problem here.
Chrome (14.0.835.35 beta-m) + Windows 7 takes about 30 seconds to connect
and after connecting it's too slow to be usable.
Most of the time it even disconnects after a while.

Safari + Windows 7 and Chrome (13.0.782.112) + Ubuntu 10.04 are super fast
and stable and I'm not having any problems with Firefox too.

Other info: Running Socket.io with Nowjs on Nodester.

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

Guillermo Rauch
LearnBoost CTO
http://devthought.com

[scanferla]

Thanks! :)

[scanferla]

Actually, "thanks" doesn't represent how grateful I am and many many others must be too. For all your work.

[ronkorving]

Great work guys! A big thanks indeed.
I'm looking forward to the update.

[bdickason]

Completely agree with the comments thus far. This project is phenomenal :)

[denisu]

Yep, awesome work, my favorite project so far! :)

[akumpf]

Socket.io is excellent.

I am also experiencing the "warn - websocket connection invalid" when using Chrome and Socket.io 0.7.9 (via the Now.JS package). Thank you for working to support HyBi 10 so quickly -- looking forward to the upcoming commit!

[akumpf]

Not sure if this is directly helpful, but there's some info about ways to implement Hybi10 here:
https://github.com/miksago/node-websocket-server/issues/72#issuecomment-1815709

[gavinuhma]

+1

[akumpf]

Any timing info on Hybi 10 support in Socket.io? Would love to get websockets working with Chrome again :)

Perhaps implementation help here: https://github.com/Worlize/WebSocket-Node

[BinaryMuse]

Commenting to get myself on the email list for this issue. Thanks for all your hard work on Socket.IO!

[CvX]

@BinaryMuse there's a "Enable notifications for this Issue" link on the bottom of the page.

[BinaryMuse]

@CvX Aha! Hooray for reading! I swear I looked for such an option before commenting. ;) Thanks.

[theturtle32]

Apologies... I posted some lengthy comments on this issue on the bug for socket.io-client when I should have posted them here:

I wrote a WebSocket library for node that is a fairly comprehensive implementation of the latest protocol draft with exhaustive documentation. I sent a gist that shows a simplistic initial integration with Socket.IO to @guille about a month ago but I haven't heard anything in response. Must be swamped with work. I'm not at all familiar with the Socket.IO internals, so I mostly just hacked away at the existing websocket backend to get it to work (read: don't use this hack in production.) To try it out, replace lib/transports/websocket.js on the server, add "websocket": ">=0.0.13" to the package.json, and run "npm install"

https://gist.github.com/1094399

note: this will only work with the new browsers and will break websocket support on the chrome <14 etc. because I didn't add the new draft implementation as a separate transport. For chrome at least, no changes to the client are required. Firefox 7 will require checking for the prefixed MozWebSocket constructor and using that if its there.

Implementing the current draft is an order of magnitude more complex than implementing draft-76 was. It has a stateful binary framing protocol now and support for raw binary messaging, ping/pong, message fragmentation etc., whereas before there were only text messages delimited with sentinel characters. There is a lot more complexity and a lot more places for obscure bugs to creep in. I decided to only implement a singular version of the protocol in my library (the latest draft) because the browsers in the wild that are implementing the new drafts will be quickly updated through their auto-update mechanism and it's not worth the substantial code complication to support 5 simultaneous protocol versions. Firefox 6 that supports draft-07 will only be out for 6 weeks before Firefox 7 that has draft-10 replaces it automatically. Likewise with chrome... in less than 5 weeks almost all chrome users that are currently on draft-76 will automatically update to draft-10. The one straggler will be Safari, unfortunately. So I'm tracking with (and usually several weeks ahead of) the browser releases. Once the protocol is finalized (which should be very soon) it'll stabilize. Thank God for Chrome and Firefox's auto-updating! For something like Socket.IO it would be very easy to keep the existing parser to support Draft-76 and just add a new library like WebSocket-Node for Draft-10 connections (probably use two separate transports "websocket-76" and "websocket-10" with some client-side detection logic.)

[einaros]

I've made a push to implement hybi10 support as transparently as possible on top of socket.io 0.7.9. My fork can be found at https://github.com/einaros/socket.io.

The 'send' framing of the hybi10 implementation was taken from steveWang's io.socket (https://github.com/steveWang/io.socket). The rested was thrown together from reading the websocket draft.

I've include tests for hybi10 specific parser cases, in test/transport.websocket.hybi10-parser.test.js. These cases include fragmented messages, ping packets in-between fragments of text packets, tcp fragmentation in addition to message fragmentation etc.

Suggestions are more than welcome - I've basically just implemented whatever I had to add to get http://draw.2x.io working with the newest browsers. That said, it seems stable for now :-)

[steveWang]

By the way, a quick heads up -- sending a very long message (I think the cap is 32767) breaks the new websocket implementation (in Chrome, at least) for some reason. What needs to be done is some form of chunking of messages and reassembly by the recipient; I'll probably get on that at some point in the next few weeks.

[einaros]

@steveWang, I read some comments about that somewhere (possibly yours), but haven't gotten around to testing it.

I just pushed a cap+tests for 32 bit packet length, even though the protocol allows 64 bit. Even 32 bit seems ludicrous for javascript, in my humble opinion. If nothing else, it certainly welcomes DoS attacks.

[einaros]

@ronkorving, Chrome 15.0.865.0 works just fine here. Make sure you aren't actually still running some older socket.io version.

[mfkp]

@ronkorving My Chrome 15.0.865.0 works fine, as well as 14.0.835.109.

[ronkorving]

My bad, it does work. But it showed a new bug. I am transferring a relatively large amount of data through Socket.IO (though not beyond say 50KB), and I get the following error in my Chrome console:

"WebSocket frame length too large: 13907115651451328556 bytes"

I'm pretty sure I am not trying to send 13907115651451328556 bytes :)

I guess this may be a known issue?

[einaros]

@ronkorving Seeing as that message stems from Chrome, it may be an issue there. I've tested my hybi10 implementation against payloads way beyond 50kB, so that shouldn't be an issue.

Remember that you're currently running an alpha version of Chrome :)

[scanferla]

Please don't close it yet.

I've noticed a "serious" problem with this last Socket.io version.

Messages with characters like é, ó, ã, ô etc... are not being delivered anymore (chat). And I don't know why or what happens (sorry).

My simple² test:
From Chrome to Chrome: Not working...
From Chrome to Firefox: Not working...
From Firefox to Chrome: Working! Why?! hehe
From Firefox to Firefox Not working...

My bet is that it's something related to utf-8 or anything like that. But I really don't know.

And thanks, it's working perfectly on Chrome! (except this issue I just mentioned)

:)

[scanferla]

Just in case: I'm running Node v0.4.8

[einaros]

@scanferla, Looking into it right now.
@ronkorving, I also found an issue in the outgoing message framing in the hybi10 implementation - the part I didn't write myself. I'm guessing that's the part your Chrome is nagging about.

[einaros]

@ronkorving, Sending more than 64kB of data from server to client is now fixed in https://github.com/einaros/socket.io.

[einaros]

@scanferla, I'll have a fix for the utf-8 issue in an hour or two. I see there's something off there, but will have to investigate a little bit further.

[scanferla]

@einaros, thank you so much! :)

[einaros]

@scanferla, Alright, it should be good now. Check the https://github.com/einaros/socket.io fork.

@steveWang, You might want to check my updates and update your send framing in your IO.Socket project. I yanked that code from you, and found a few bugs in both utf-8 handling (string length != byte length of a utf-8 string) and >64kB data length output.

[ronkorving]

@einaros, I happily and gratefully confirm that your fork fixes the problem here!

[nookiepl]

Fixes problem here too. Thanks! Should be merged with official branch ASAP! :)

[einaros]

@nookiepl, I'm sure it will be, when @guille wakes up.

[scanferla]

@einaros, thank you!

Will wait this commit to be merged. (all others already were)

If it takes too long, how can I use your fork with my project? Can I just download / clone your repo and replace my socket.io folder?
As npm can't install your fork, or can it?
Sorry for the "silly" question, but I'm just starting with Node.js :)

Thanks again.

[einaros]

@scanferla, You can clone my fork into whichever node_modules folder socket.io has already been installed to, granted that you remove the previous one. Otherwise wait for a merge :)

[scanferla]

@einaros, cool!
Great³ work and unbelievable fixing and replying speed and quality!

:)

[scanferla]

Just to let everyone know: It was merged and it's working perfectly!

IMHO we can close this issue

[terzza]

Working fine here too (Chrome 15 / Ubuntu Natty)
Thank you

[3rd-Eden]

Closing, fixed in Socket.IO 0.8

[ruimarinho]

What an awesome work! Thank you!

[ronkorving]

Thanks for the awesome and quick work guys!

Just a quick warning for the near future. According to the last sentence in this article ( http://peter.sh/2011/08/fullscreen-api-enhanced-element-highlighting-and-progress-on-flexbox/ ) we'll soon see another update to the WebSocket implementation in Chromium: https://bugs.webkit.org/show_bug.cgi?id=67115

[einaros]

@ronkorving, binary transport isn't used by socket.io at present in either
case, so that shouldn't be an issue.

On Aug 30, 2011 3:50 AM, "ronkorving" <
reply@reply.github.com>
wrote:

Thanks for the awesome and quick work guys!

Just a quick warning for the near future. According to the last sentence
in this article (
http://peter.sh/2011/08/fullscreen-api-enhanced-element-highlighting-and-progress-on-flexbox/)
we'll soon see another update to the WebSocket implementation in
Chromium:
https://bugs.webkit.org/show_bug.cgi?id=67115

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

[zzo]

it's borked again(?)/still(?) in Chrome 16.0.912.63 on Mac OSX at least

[zzo]

debug - setting request GET /socket.io/1/websocket/13496148131557414773
debug - set heartbeat interval for client 13496148131557414773
warn - websocket connection invalid
info - transport end

[zzo]

% npm list sez:
├─┬ socket.io@0.8.4
│ ├── policyfile@0.0.4
│ ├── redis@0.6.6
│ └─┬ socket.io-client@0.8.4
│ ├── uglify-js@1.0.6
│ ├── websocket-client@1.0.0
│ └── xmlhttprequest@1.2.2

[jmstout]

@zzo using the 0.8.7 found here worked to fix this issue for me:
https://github.com/einaros/socket.io