Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Socket.io 1.0

socket.io

Post reply on HN
Print view View original

41–50 of 76 posts

Re: Introducing Socket.io 1.0

#41

Post by EGreg »

V1 wrote: post #37
tlrobinson wrote: post #10

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 Gluing together various types of streams and stream transformers is a really nice…

You could also just use Primus which exposes a Stream compatible wrapper by default for the client and server. https://github.com/primus/primus (Primus uses engine.io,sockjs,browserchannel,websockets internally so you're no longer locked into a specific framework)

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?

Re: Introducing Socket.io 1.0

#43

Post by modarts »

arbus wrote: post #36

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 s…

https://github.com/codeparty/racer

Re: Introducing Socket.io 1.0

#46

Post by 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

Re: Introducing Socket.io 1.0

#47

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

Re: Introducing Socket.io 1.0

#48

Post by tlrobinson »

bryanlarsen wrote: post #19
tlrobinson wrote: post #10

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 Gluing together various types of streams and stream transformers is a really nice…

what about https://www.npmjs.org/package/socket.io-stream ?

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.

Re: Introducing Socket.io 1.0

#50

Post by lpinca »

EGreg wrote: post #41
V1 wrote: post #37

Earlier quoted context omitted.

You could also just use Primus which exposes a Stream compatible wrapper by default for the client and server. https://github.com/primus/primus (Primus uses engine.io,sockjs,browserchannel,websockets internally so you're no longer locked into a specific framework)

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?

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.
Post reply on HN