Finally! It's been a long time coming. Thanks for your hard work!
Introducing Socket.io 1.0
11–20 of 76 posts
Re: Introducing Socket.io 1.0
#12I've since switched to SockJS for all of my projects (after struggling with memory issues in Socket.io 0.9.*). Any compelling reasons to give Socket.io another try?
The new engine.io module used behind the scenes is amazing. It will start with long polling, and upgrade to WebSockets seamlessly (so you get a very fast start every time, even in old browsers or proxied envs). AFAIK, this is the opposite of what was happening previously (trying WebSockets, then falling back to long polling). Engine.io is also much more scalable and robust.
Disclaimer: I work at Automattic, we've been using engine.io on cloudup.com for a while.
Re: Introducing Socket.io 1.0
#13I've been using engine.io directly in production for quite a while, and it's been stable and reliable. Glad to see this release, having the option of going back to the higher-level socket.io api is welcome.
Re: Introducing Socket.io 1.0
#14Congrats Guillermo and everyone involved!
Re: Introducing Socket.io 1.0
#15This seems like a good place to ask: Does anyone know of a library (preferably C++/Emscripten) that simplifies using WebRTC to create real time network games?
Re: Introducing Socket.io 1.0
#16Congrats 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 to the same server. This is OK, but what about nodeJS clusters? How should I ensure that client A always connects to cluster-node member 3?
Related section of the blog post: http://socket.io/blog/introducing-socket-io-1-0/#scalability
Re: Introducing Socket.io 1.0
#17Great.
offtopic: please fix your blog, it breaks the browser history in IE 11 (spammed with hash entries)
Re: Introducing Socket.io 1.0
#18This seems like a good place to ask: Does anyone know of a library (preferably C++/Emscripten) that simplifies using WebRTC to create real time network games?
If it fits your needs why not Socket.io? They now support redis emission which means all these langs work: http://redis.io/clients
Re: Introducing Socket.io 1.0
#19I like the separation of the transports into engine.io, however it would be even better if it exposed a standard Node.js Stream interface so that it played nicely with the growing ecosystem of Stream-related modules. Dominic Tarr, substack, and others have been advocating this idea for awhile: https://github.com/substack/stream-handbook Gluing together various types of streams and stream transformers is a really nice…
what about https://www.npmjs.org/package/socket.io-stream?
Re: Introducing Socket.io 1.0
#20Congrats 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.