8 ms·

Introducing Socket.io 1.0

498 points by rafaelc 12y ago

liamk 12y ago
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).
EGreg 12y ago
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!
eob 12y ago
Congrats Guillermo and gang!
woah 12y ago
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 12y ago
  Please read the "Scalability" section on the blog post! This very demo is fully clustered.
  - thedufer 12y ago
    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.
- thedufer 12y ago
  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.
  - mpetrov 12y ago
    Sticky load balancing was a deal breaker for us when we built the https://map.couple.me https://map.couple.me visualization with socket.io. At the last minute I just pulled older browser support and left it with raw websockets instead of socket.io because the cluser module couldn't be used otherwise. We had two issues with sticky load balancing: 1. AWS ELB had to run in TCP mode (for websockets) which meant no stickiness 2. Within each instance we have a node-cluster running to utilize multiple CPUs and putting haproxy with stickiness there increased complexity We could avoid using the ELB but then you lose the ability to use an EC2 Auto Scaling group, introducing significant admin overhead. Ultimately we didn't need the nodes communicating between each other (it's a one way stream from us to the client) so raw websockets ended up being the simplest solution.
lucidrains 12y ago
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 12y ago
  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 12y ago
    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.
buckbova 12y ago
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.
bedane 12y ago
Excellent news, looking forward to using it. socket.io is awesome !
tlrobinson 12y ago
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 12y ago
  what about https://www.npmjs.org/package/socket.io-stream https://www.npmjs.org/package/socket.io-stream?
  - tlrobinson 12y ago
    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.
- V1 12y ago
  You could also just use Primus which exposes a Stream compatible wrapper by default for the client and server. https://github.com/primus/primus https://github.com/primus/primus (Primus uses engine.io,sockjs,browserchannel,websockets internally so you're no longer locked into a specific framework)
  - EGreg 12y ago
    someone should do primus vs socket.io why would I need engine.io,websockets for example when engine.io already uses websockets if it can upgrade the connection to them?
    - lpinca 12y ago
      You can't use both. In Primus you can select only one transformer, listed above by V1, but if something doesn't work, you can just switch it with a single line of code. No rewrites, no need to learn a new API.
ChrisGaudreau 12y ago
Finally! It's been a long time coming. Thanks for your hard work!
ef4 12y ago
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.
mmanfrin 12y ago
Congrats Guillermo and everyone involved!
Timmmmbob 12y ago
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?
- Goopplesoft 12y ago
  If it fits your needs why not Socket.io? They now support redis emission which means all these langs work: http://redis.io/clients http://redis.io/clients
- srpeck 12y ago
  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
  - spb 12y ago
    If you want a simpler signaling server for WebRTC, you might check out the "caress" server I developed for Chatphrase: http://github.com/chatphrase/caress http://github.com/chatphrase/caress
  - samdutton 12y ago
    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.
evantahler 12y ago
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 12y ago
  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 12y ago
    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.
  - kevinbowman 12y ago
    I concur; we use sticky-sessions in our load-balancer, and stunnel when we're doing it on an SSL'd page, and it's working just fine.
- evantahler 12y ago
  As a note, I switched to Faye for most of my websocket needs because of this http://faye.jcoglan.com/ http://faye.jcoglan.com/
  - mpetrov 12y ago
    I tried using faye and it died very quickly under load with the redis backend. For every message that you send it queues it up into a redis list for each faye server in the cluster to read which doesn't scale very well in their very chatty redis queue system. I would do significant load testing for each use case before using it (or socket.io for that matter). I needed to push 30-50 messages per second to each connected client and faye started choking as soon as there were more than 20-30 clients. socket.io would choke at around 50-100 connected clients. Raw websockets were able to reach closer to 100 clients but performed more or less similar to socket.io.
frik 12y ago
Great. offtopic: please fix your blog, it breaks the browser history in IE 11 (spammed with hash entries)
- gavinpc 12y ago
  As long as we're off topic, I think the OP means to say that "The benefits of this particular modularization can’t be overstated"
dydx 12y ago
I've been waiting for this for so long. Thanks Guillermo!
xhrpost 12y ago
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 12y ago
  I solved this by firing an event on window.beforeunload. Had the same issue.
emp_ 12y ago
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 12y ago
  That iframe is simply pointing to http://socket.computer http://socket.computer (yes, the new .computer TLD is here)
chunkstuntman 12y ago
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.
level09 12y ago
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.
uses 12y ago
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 12y ago
  It's almost certainly the multiple animations (<video> elements) on the page.
- bluejellybean 12y ago
  I'm having the exact same issue.
ivank 12y ago
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 12y ago
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 ?
arbus 12y ago
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 12y ago
  https://github.com/codeparty/racer https://github.com/codeparty/racer
  - arbus 12y ago
    Thank you, will check it out
lpinca 12y ago
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.
spb 12y ago
Finally.
brianzelip 12y ago
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/
jeffasinger 12y ago
I'm really excited about this. Anyone know of any projects working towards getting this new version to work on native iOS/Android?
Oculus 12y ago
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
- weixiyen 12y ago
  > Socket.io has been plagued with scalability issues since its original release How does that affect scalability, or how is that related to your comment?
- Vekz 12y ago
  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
mmcclure 12y ago
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.
granttimmerman 12y ago
Awesome!!! Can't wait for the future of IO.
8ig8 12y ago
It sounds like Automattic deserves some thanks for their support on this. Thank you.
- rafaelc 12y ago
  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
sirdogealot 12y ago
>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.
mkoryak 12y ago
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 12y ago
  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.
cridenour 12y ago
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 12y ago
  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.
talyssonoc 12y ago
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 ?
rootuid 12y ago
socket.io has 635 open issues. Seriously !
laxk 12y ago
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?

498 points by rafaelc 12y ago

liamk 12y ago

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).

EGreg 12y ago

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!

eob 12y ago

Congrats Guillermo and gang!

woah 12y ago

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 12y ago
Please read the "Scalability" section on the blog post! This very demo is fully clustered.
- thedufer 12y ago
  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.
thedufer 12y ago
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.
- mpetrov 12y ago
  Sticky load balancing was a deal breaker for us when we built the https://map.couple.me https://map.couple.me visualization with socket.io. At the last minute I just pulled older browser support and left it with raw websockets instead of socket.io because the cluser module couldn't be used otherwise. We had two issues with sticky load balancing: 1. AWS ELB had to run in TCP mode (for websockets) which meant no stickiness 2. Within each instance we have a node-cluster running to utilize multiple CPUs and putting haproxy with stickiness there increased complexity We could avoid using the ELB but then you lose the ability to use an EC2 Auto Scaling group, introducing significant admin overhead. Ultimately we didn't need the nodes communicating between each other (it's a one way stream from us to the client) so raw websockets ended up being the simplest solution.

lucidrains 12y ago

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 12y ago
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 12y ago
  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.

buckbova 12y ago

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.

bedane 12y ago

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

tlrobinson 12y ago

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 12y ago
what about https://www.npmjs.org/package/socket.io-stream https://www.npmjs.org/package/socket.io-stream?
- tlrobinson 12y ago
  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.
V1 12y ago
You could also just use Primus which exposes a Stream compatible wrapper by default for the client and server. https://github.com/primus/primus https://github.com/primus/primus (Primus uses engine.io,sockjs,browserchannel,websockets internally so you're no longer locked into a specific framework)
- EGreg 12y ago
  someone should do primus vs socket.io why would I need engine.io,websockets for example when engine.io already uses websockets if it can upgrade the connection to them?
  - lpinca 12y ago
    You can't use both. In Primus you can select only one transformer, listed above by V1, but if something doesn't work, you can just switch it with a single line of code. No rewrites, no need to learn a new API.

ChrisGaudreau 12y ago

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

ef4 12y ago

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.

mmanfrin 12y ago

Congrats Guillermo and everyone involved!

Timmmmbob 12y ago

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?

Goopplesoft 12y ago
If it fits your needs why not Socket.io? They now support redis emission which means all these langs work: http://redis.io/clients http://redis.io/clients
srpeck 12y ago
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
- spb 12y ago
  If you want a simpler signaling server for WebRTC, you might check out the "caress" server I developed for Chatphrase: http://github.com/chatphrase/caress http://github.com/chatphrase/caress
- samdutton 12y ago
  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.

evantahler 12y ago

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 12y ago
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 12y ago
  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.
- kevinbowman 12y ago
  I concur; we use sticky-sessions in our load-balancer, and stunnel when we're doing it on an SSL'd page, and it's working just fine.
evantahler 12y ago
As a note, I switched to Faye for most of my websocket needs because of this http://faye.jcoglan.com/ http://faye.jcoglan.com/
- mpetrov 12y ago
  I tried using faye and it died very quickly under load with the redis backend. For every message that you send it queues it up into a redis list for each faye server in the cluster to read which doesn't scale very well in their very chatty redis queue system. I would do significant load testing for each use case before using it (or socket.io for that matter). I needed to push 30-50 messages per second to each connected client and faye started choking as soon as there were more than 20-30 clients. socket.io would choke at around 50-100 connected clients. Raw websockets were able to reach closer to 100 clients but performed more or less similar to socket.io.

frik 12y ago

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

gavinpc 12y ago
As long as we're off topic, I think the OP means to say that "The benefits of this particular modularization can’t be overstated"

dydx 12y ago

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

xhrpost 12y ago

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 12y ago
I solved this by firing an event on window.beforeunload. Had the same issue.

emp_ 12y ago

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 12y ago
That iframe is simply pointing to http://socket.computer http://socket.computer (yes, the new .computer TLD is here)

chunkstuntman 12y ago

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.

level09 12y ago

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.

uses 12y ago

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 12y ago
It's almost certainly the multiple animations (<video> elements) on the page.
bluejellybean 12y ago
I'm having the exact same issue.

ivank 12y ago

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 12y ago

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 ?

arbus 12y ago

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 12y ago
https://github.com/codeparty/racer https://github.com/codeparty/racer
- arbus 12y ago
  Thank you, will check it out

lpinca 12y ago

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.

spb 12y ago

Finally.

brianzelip 12y ago

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/

jeffasinger 12y ago

I'm really excited about this. Anyone know of any projects working towards getting this new version to work on native iOS/Android?

Oculus 12y ago

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

weixiyen 12y ago
> Socket.io has been plagued with scalability issues since its original release How does that affect scalability, or how is that related to your comment?
Vekz 12y ago
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

mmcclure 12y ago

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.

granttimmerman 12y ago

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

8ig8 12y ago

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

rafaelc 12y ago
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

sirdogealot 12y ago

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

mkoryak 12y ago

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 12y ago
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.

cridenour 12y ago

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 12y ago
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.

talyssonoc 12y ago

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 ?

rootuid 12y ago

socket.io has 635 open issues. Seriously !

laxk 12y ago

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?