[ANN] Socket.IO 0.5 is out

[Guillermo Rauch]

Hey,

Socket.IO and Socket.IO-node 0.5 are out. While there're some new features, the bigger changes make Socket.IO now more lightweight, simpler, stable and easier to use.

* Socket.IO no longer requires JSON for the transmission of messages. This eliminates the dependency on JSON.js on the client, and makes it faster for Socket.IO to encode/decode messages (specially if several are buffered).

* All external dependencies have been removed from both the server and client. The client as a result is more lightweight, and the server has zero submodule dependencies to run.

* Automated tests were incorporated into the server through expresso (thanks TJ) and node-websocket-client (thanks pgriess). For 1.0 I'll have more extensive test coverage, but feel free to contribute.

* Implemented heartbeats and timeouts as a measure to prevent connection starvation and as an absolute way to detect disconnections (a common example would be when connections don't fire the `end` event due to not being properly terminated -sending a FIN packet-).

* Updated web-socket-js Flash client (thanks gimite) to the latest version, which supports the latest WebSocket draft. For 1.0 I'll be able to completely eliminate support for older versions of the WebSocket protocol (which are considered less secure).

* Improved the events triggered by clients/server. This is what the Socket.IO server setup looks like now:

var socket = io.listen(server);

socket.on('connection', function(client){

 // new client is here!

 client.on('message', function(){ … })

 client.on('disconnect', function(){ … })

});

* Many other bugfixes, leveraged module.exports more, etc

* Client tested on

- Safari 4

- Google Chrome 5

- Internet Explorer 6

- Internet Explorer 7

- Internet Explorer 8

- iPhone Safari

- iPad Safari

- Firefox 3

- Firefox 4 (Minefield)

http://github.com/LearnBoost/Socket.IO-node/downloads

--
Guillermo Rauch
http://devthought.com

[Renato Elias]

Cool

I will go test in nexus one tomorrow

Cya

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

[Guillermo Rauch]

Awesome. I'd also like feedback as to side effects of long-polling in different mobile devices. For example, iPhone shows a progress bar continually, which sort of sucks (although it can be prevented for web apps triggered from homescreen, and I think there's a <meta> for hiding the url bar but I'm not sure).

[Isaac Z. Schlueter]

Hey, Guillermo, this looks really cool.

I just sent a pull request with a package.json, and published 0.5.1 to
the npm registry. If you'd like to own that process, that'd be great.

--i

[tjholowaychuk]

wahoo!

[Matt Stevens]

I did some mobile device testing with the chat demo:

iOS 3.2: Works
iOS 4.0.1: Works
webOS 1.4.1: Works
Android 2.1: Fails, tries to use flashsocket. Works with xhr-polling.

None of the devices were able to recover reliably from extended sleep
or movement between Wi-Fi and cellular data. This is difficult support
through transport alone since the XHR can get into a state where it
waits a long time to timeout even though Wi-Fi is up and running
again. Listening for the online and offline events where available can
help though.

As for side effects:

There was a bug with XHR long polling in iOS 2 & 3: resource requests
were distributed across the two active connections and remained in
their assigned connection's queue regardless of whether the other
connection was free. This meant that an XHR long poll could block
loading of images and other resources until it received a response or
was aborted. I don't know if this was ever fixed.

If it is feasible for the page, implementors can hack around the stuck
progress bar on Android and iOS by deferring socket.connect() until
after window.onload. Adding a setTimeout(func, 100) in the load event
handler should do it. Unfortunately there is timing involved, if
anyone knows of a better event to listen for I'd love to hear about
it.

BTW: Github doesn't support submodules in download archives so they're
missing the example client content.

Matt

[Guillermo Rauch]

Matt,

This is amazing feedback, thanks! I have enough material to have fun.

Since socket.connect() in the client is async, and subsequent .send() calls are queued until it's connected, 

we can perfectly delay the actual connection until the page is loaded for mobile devices, which apparently sounds like a good idea.

I didn't know that about GitHub, that kinda sucks!

[Peter Hewat]

Hi Guillermo,

Do you know how many concurrent clients can connect to a Socket.IO
server?

Keep up the good work :)

Cheers,
Peter

[TedBeer]

On Jul 30, 4:26 am, Matt Stevens <m...@alloysoft.com> wrote:

> As for side effects:
>
> There was a bug with XHR long polling in iOS 2 & 3: resource requests
> were distributed across the two active connections and remained in
> their assigned connection's queue regardless of whether the other
> connection was free. This meant that an XHR long poll could block
> loading of images and other resources until it received a response or
> was aborted. I don't know if this was ever fixed.

I had similar problem in Safari 4 for Windows! Loading images
specified
in css was blocked by early started long polling connection (DWR was
used)
despite supporting several multiple connections in the browser. In a
minute
when the first connection is closed by timeout loading images
resumes.
So could it be just Apple Webkit quirks?

[Guillermo Rauch]

It probably is just WebKit, I'll perform some tests. I guess if transport xhr-polling is the one to be used, we're probably better off by delaying the XHR connection until the page is loaded.

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.