I've been waiting for this for so long. Thanks Guillermo!
Introducing Socket.io 1.0
21–30 of 76 posts
Re: Introducing Socket.io 1.0
#22Congrats on the release! I know this was a long time coming. A scalability question: You note "Turn on sticky load balancing (for example by origin IP address). This ensures that long-polling connections for example always route requests to the same node where buffers of messages could be stored." I read this to mean that we are responsible (in our load balancer/proxy/etc) to keep connections from clients returning t…
The node.js cluster module is not flexible enough to be used with engine.io / socket.io / sockjs etc. Just run several processes and put something like HAproxy in front of them. If using a cookie to ensure stickiness, you can scale to multiple load-balancers easily.
That seems like a pretty big requirement that could frequently be deal-breaking. I would expect a big warning somewhere that you can't cluster if you're using socket.io.
Re: Introducing Socket.io 1.0
#23I've used Socket.IO quite a bit, congrats on shipping! Did the issue/"lack of feature" get fixed where not all transport methods fire a disconnect event? That was especially a pain on a recent project, ended up forcing websocket only to get around it.
EDIT: Ack, I should probably clarify this better. The issue is that a client disconnected is not determined by the server. The server waits for the client to send a disconnect event to it prior to leaving the page. This is particularly a problem on iPad where the event will not fire for certain transports so disconnect doesn't fire when you shut off an iPad unless websockets are actively used.
Re: Introducing Socket.io 1.0
#24Have you guys dealt with the 3-year clustering bug? https://github.com/Automattic/socket.io/issues/438 Would be pretty hesitant to use it until there's some sort of closure on this.
It appears that the answer is "kind of". You can't use cluster, but you can put multiple processes behind a load balancer if the load balancer can do sticky routing. They should probably be a lot more explicit about this; the scalability section seems to avoid mentioning that socket.io isn't compatible with the cluster module.
Re: Introducing Socket.io 1.0
#25I wish there was more info on the CS 1.6 demo, is there an address to look at it?
EDIT: found it at http://socket.io/demos/computer/
Re: Introducing Socket.io 1.0
#26This library was intuitive enough to learn in a few hours and allowed me to make a fun toy project in half a day. Highly endorsed.
Re: Introducing Socket.io 1.0
#27wow that is cool. last time I tried it I had a hard time struggling with HAProxy and trying to fix the sticky session thing.
Would be great to see some benchmark of how this can scale especially with the new redis integration.
Re: Introducing Socket.io 1.0
#28Something about this site just kills both Firefox and Chrome on my Windows 7 computer: everything becomes choppy and laggy, even outside the browser. On both browsers, things return to normal when I close the tab.
Task Manager shows no unusual CPU activity beyond the initial page load.
Re: Introducing Socket.io 1.0
#29You need mandatory ACKs in both directions if you want to implement a reliable stream over HTTP requests. Otherwise, data can get lost in several scenarios, including: server responds to a long-poll request, connection breaks before client receives it, server assumes the data arrived, user never sees the message. Instead of having an ACK for every message in both C2S and S2C directions, socket.io implements some kind of bizarre optional-per-message ACK functionality that you manage with callbacks. There are libraries/protocols that do this right, including Closure Library's BrowserChannel.
Re: Introducing Socket.io 1.0
#30How does the binary support/performance and streaming support (with socket.io-stream) compare to other web socket libs like https://github.com/binaryjs/binaryjs, https://github.com/einaros/ws and https://github.com/maxogden/websocket-stream ?