
Introducing Socket.io 1.0 - rafaelc
http://socket.io/blog/introducing-socket-io-1-0/
======
tlrobinson
I 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](https://github.com/substack/stream-handbook)

Gluing together various types of streams and stream transformers is a really
nice way to build certain types of applications.

Fortunately it should be easy to write a Stream compatible wrapper.

~~~
bryanlarsen
what about [https://www.npmjs.org/package/socket.io-
stream](https://www.npmjs.org/package/socket.io-stream)?

~~~
tlrobinson
That probably works fine, but if it's encapsulating a stream over Socket.io's
protocol then it's going to be much less efficient than the other way around.

------
Oculus
The undoubtable mention of SockJS will appear multiple times in this thread.
Socket.io has been plagued with scalability issues since its original release
(can't speak on the new version) and Engine.io is suppose to be fix that. The
main difference between SockJS & Socket.io is their connection establishment.
SockJS begins by attempting to use Websockets and regress to long polling
while Engine.io starts with long polling and slowly works its way up to
Websockets.

For a good debate on this with the creator of SockJS:
[https://groups.google.com/forum/#!topic/sockjs/lgzxVnlth54](https://groups.google.com/forum/#!topic/sockjs/lgzxVnlth54)

~~~
Vekz
I second @weixiyen. You bring up "Socket.io has been plagued with scalability"
and then elaborate on the irrevalant graceful degradation strategies of each
framework

------
lucidrains
I'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?

~~~
TheCoreh
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.

~~~
Zarel
When I switched to SockJS, I tried Engine.io too, but I ended up going with
SockJS mostly because Engine.io didn't expose the client's IP address to Node,
which made IP banning impossible. It looks like it's still an issue, sadly.

------
evantahler
Congrats 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](http://socket.io/blog/introducing-socket-
io-1-0/#scalability)

~~~
onestone
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.

~~~
thedufer
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.

------
liamk
This was a long time coming! I'm very happy to see socket.io 1.0 finally
released. Pre-1.0 had some deal-breaking technical issues, such as starting
with websockets and falling back to polling. I think the new approach is
starting with polling and then seeing if a) websockets are supported by the
current browser and b) messages sent via websocket are received by the server
(a firewall might prevent this).

------
woah
Have you guys dealt with the 3-year clustering bug?
[https://github.com/Automattic/socket.io/issues/438](https://github.com/Automattic/socket.io/issues/438)

Would be pretty hesitant to use it until there's some sort of closure on this.

~~~
Rauchg
Please read the "Scalability" section on the blog post! This very demo is
fully clustered.

~~~
thedufer
Its dependent on sticky load balancing - a pretty big caveat. And as far as I
can tell, it still doesn't work with the cluster module, which is what that
issue is about.

------
uses
Something 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.

~~~
alelefant
It's almost certainly the multiple animations (<video> elements) on the page.

------
xhrpost
I'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.

~~~
antonapa
I solved this by firing an event on window.beforeunload. Had the same issue.

------
ivank
You 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.

------
rationalthug
How 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/binaryjs/binaryjs),
[https://github.com/einaros/ws](https://github.com/einaros/ws) and
[https://github.com/maxogden/websocket-
stream](https://github.com/maxogden/websocket-stream) ?

------
lpinca
Congrats for the release, but i will keep using
[https://github.com/primus/primus](https://github.com/primus/primus).

No module lock-in!

Yes i'm a bit biased.

------
mmcclure
I knew things were changing in 1.0, but there are a lot of things mentioned in
that blog post that seriously make me giddy. I'm really, really excited to
play with this tonight.

Also, incredible job on the new website. Seriously love it. All around great
work, if there was a Gittip button on the website I would have already clicked
it.

------
arbus
A kind of OT question related to socket.io.

I am trying to develop an application that can be horizontally scaled. I
understand using the socket.io-redis package seems to allow you to emit to a
particular socketid from one instance while that connection itself is
connected to another machine and the redis connection will take care of the
communicating. This in a sense abstracts away the fact that there are multiple
servers by just taking care of it transparently.

Are there any provisions within socket.io or another package that allows you
to sync normal js objects across servers as well? The alternative as I see it
is to use redis pub/sub to keep the state in sync but this feels like it
should be a solved problem that one need not reinvent the wheel for.

~~~
modarts
[https://github.com/codeparty/racer](https://github.com/codeparty/racer)

~~~
arbus
Thank you, will check it out

------
emp_
I 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/](http://socket.io/demos/computer/)

~~~
TooTallNate
That iframe is simply pointing to
[http://socket.computer](http://socket.computer) (yes, the new .computer TLD
is here)

------
buckbova
This is exactly how I've always wanted the web to work. i've spent some time
with socket.io working through "nodejs in action" and I can't wait to use it
for new apps.

------
EGreg
Finally!! I was going to switch to naked engine.io because it can handle many
more connections without going crazy. Now I can get it without changing my
code. Woo hoo!

------
Timmmmbob
This 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?

~~~
srpeck
I looked for a library for a similar WebRTC project. All of the libraries I
found contained superfluous functionality, as I was only interested in data
channels and did not want to be locked in by a particular third party. I ended
up rolling my own; the WebRTC API is simple enough [1] and there is some
example code from Google that points the right direction [2]. Additionally,
Socket.io makes for a convenient signalling server prototype, though it is
overkill.

[1]
[http://dev.w3.org/2011/webrtc/editor/webrtc.html](http://dev.w3.org/2011/webrtc/editor/webrtc.html)

[2]
[https://bitbucket.org/webrtc/codelab](https://bitbucket.org/webrtc/codelab)

~~~
samdutton
You might also find something useful at
[http://bit.ly/webrtcwebaudio](http://bit.ly/webrtcwebaudio). PeerJS is a
library oriented to data exchange: [http://peerjs.com](http://peerjs.com).

------
jeffasinger
I'm really excited about this.

Anyone know of any projects working towards getting this new version to work
on native iOS/Android?

------
mkoryak
demo on [http://socket.computer](http://socket.computer) \- err, I knew new
TLDs might be fairly annoying but didnt think they would totally break my
brain's URL parser.

At first I thought that the article's author forgot to replace an intranet
link.. nope its a new tld here to mess with our heads!

~~~
squidsoup
Sadly TLDs are really getting out of hand. I was notified today that .ninja is
now available. This coupled with Dr. Dre potentially joining the Apple board
and the TrueCrypt announcement has made for a pretty surreal day in tech news.

------
laxk
As I understand if I want to use socket.io client API I have to run node.js as
a container for socket.io server side code and then I can create a new emmiter
for my server language (similar to PHP example in the article) Is it correct?

Is it possible to create own implementation of socket.io server side code?

------
talyssonoc
Seems pretty good, and faster than the previous version, but:

\- Changed some things (method names, and so on) with no reason \- It's not
possible to use a custom logger anymore \- I can't access the list of rooms
anymore (or it changed and they didn't documented it yet)

Somebody else ?

------
ef4
I'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.

------
bedane
Excellent news, looking forward to using it. socket.io is awesome !

------
cridenour
Might I suggest you not hijack the "DEBUG" environment variable? It will
almost certainly cause issues down the line when you could be using
SOCKETIO_DEBUG.

~~~
TheCoreh
DEBUG is not solely used by socket.io, but rather by all modules that make use
of the `debug` node package:

[https://github.com/visionmedia/debug](https://github.com/visionmedia/debug)

The DEBUG variable holds a comma separated list of names (or wildcard
patterns) used to narrow the scope of the debug output.

For example, to get debug information about the internal components of
socket.io and express, you could do:

DEBUG=socket.io: _,express:_ node index.js

There really isn't a big chance of hitting problems with the DEBUG variable,
since it's defined locally to the command and not exported, and there's
already a reasonably well established convention of using it like that for
node modules.

------
chunkstuntman
This 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.

------
sirdogealot
>The Socket.IO Server is now only 1234 lines of code

I prefer to think in standardized terms like KBs, not lines of code.

EDIT: For the downvoters, I am just saying that it would have been more
beneficial to myself had they of addressed their improvement in terms of a
percentage of code reduction or actual measurable size of their code. I was
not trying to be snarky.

------
frik
Great.

offtopic: please fix your blog, it breaks the browser history in IE 11
(spammed with hash entries)

~~~
gavinpc
As long as we're off topic, I think the OP means to say that

"The benefits of this particular modularization can’t be _over_ stated"

------
8ig8
It sounds like Automattic deserves some thanks for their support on this.
Thank you.

~~~
rafaelc
They do. Worth noting that A8C acquired our company LearnBoost/Cloudup in
2013, where we had built/supported Socket.IO and many other Node.js libraries
for the prior +3 years

------
level09
wow 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.

------
ChrisGaudreau
Finally! It's been a long time coming. Thanks for your hard work!

------
brianzelip
woah, the weplay pokemon node.js emulation's chat [0] is off the chain.
Everyone controls the guy and the cursor.

[0] [http://weplay.io/](http://weplay.io/)

------
dydx
I've been waiting for this for so long. Thanks Guillermo!

------
granttimmerman
Awesome!!! Can't wait for the future of IO.

------
mmanfrin
Congrats Guillermo and everyone involved!

------
eob
Congrats Guillermo and gang!

------
rootuid
socket.io has 635 open issues. Seriously !

------
spb
_Finally._

