Welcome to another episode of This week in Node where I write about the latest update in the Node.js repository and existing updates that happen in user land.

Socket.IO 0.6.18

This week we released Socket.IO 0.6.18, which will hopefully be our last maintenance release before the much anticipated 0.7 release. While I could dedicate a whole new post on the changes that where made in 0.6.18, I will touch the surface of the most noticeable changes.

JSDocs

There is no such thing as to much documentation, with Socket.IO this is definitely the case. The main documentation for Socket.IO which be found on the website and the Github's README.md is sufficient for most users to get started with Socket.IO but it doesn't cover the details on how it actually works. Some users stated they wanted a more detailed API documentation, so we started annotating the source code. We used the JSDoc syntax which is based on the more widely known JavaDoc syntax. This allows us to easily generated API documentation and annotated source code on the fly using a JSDoc compatible parser like dox. We haven't pushed out any documentation yet but you can generate it your self with the following command:

dox --title "socket.io" socket.io.js > api.html

Reconnection support

We already announced this in the 0.6.17 release, but unfortunately we notice that we didn't update the client library inside socket.io-node. But this time we are 100% sure that it's available! Socket.IO is configured to automatically re-establish a the connection with the server when the current connection is disconnected by a transport. To prevent from creating a DOS attack on the server we have implemented a exponential back off algorithm, basically it multiplies the reconnection timeout by 2 every time it attempts to reconnect to the server. The reconnection is attempted with the same transport that was used before the connection got dropped. When the reconnection reaches the maximum allowed reconnection attempts (set to 10 by default) it will do one last attempt and try out all enabled transports.

Giving feedback to the user is always vital part of building real time application as they always expect it to work. We have implemented a couple of new events to help you with notifying your users of the reconnection process. When the reconnection has started we emit the reconnecting event and supply it with the reconnection duration for the next reconnection attempt.

// construct a socket.io instance var socket = new io.Socket(); socket.connect(); // listen for the reconnecting event socket.on('reconnecting', function(type, attempt){ console.log('Attempting to reconnect to the server. This is attempt #' + attempt); });

To know when the reconnection is successfully you can listen to the reconnect event. This event receives the transport type that was used to connect and how many attempts it took to reconnect successfully.

// handle successful reconnects socket.on('reconnect', function(type, attempts){ console.log('It only took ' + attempts ' attempts to reconnect using ' + type); });

When the reconnection is failed we emit the reconnect_failed event. We could keep attempting to reconnect to the server, at this point there must be something seriously wrong.

// handle failures socket.on('reconnection_failed', function(){ console.error('Server fail'); window.location.reload(); // use any custom logic here. });

Annoying loading spinners

Webkit based browser suffered from an annoying issue, if you create a asynchronous long polling XHR request before the document's resources are fully loaded it will keep triggering the browsers loading indicators. We solved this by doing a connect after the onload event has fired. This is the same trick that got applied to iPhone and Android devices, but it's now extended to all Webkit based browsers. This will probably make allot users happy.

Flashsocket updated to the latest version

The flashsocket fallback has been updated to the latest build. This removes the FLABridge.js dependency as the ExternalInterface is being instead. This is great news as the FLABridge.js originates from the stone age, is leaking memory as a basket and is full of code that follows worst practises on the Internet. Because of this important change inside the flashsocket we decided to test it under Opera again to see if it's more stable than the previous builds. Luckily this was the case and we enabled the flashsocket for Opera! The upgrade also solves allot of issues that users where having with cross port connections.

Removal of introduced globals

With commit 0a1a93b4846b0 allot of variables got exposed to the global scope. We have correctly identified this issue and have taken measurements to prevent this from happening. This is done with the introduction of a test suite that I have started to prototype which will hopefully be read for the 0.7 release, so stay tuned for more information about that.

For more information see the announcement on the Socket.IO google group.

node-http-proxy 5.3

More exiting new for those of us who build real time applications with the 5.3 update of Nodejitsu's node-http-proxy we can finally proxy Web Socket request! This has been plague ever since Web Sockets where added to the browsers. Most HTTP proxies do not support the HTTP 1.1 protocol. HAProxy was the only proxy available to proxy successfully proxy Web Sockets. But this was only possible in TCP mode making HTTP header inspection etc impossible. The best thing about node-http-proxy is that it only requires one line of code to get started with proxying your requests:

// proxy all requests from port 80 to port 8080, including Web Socket requests. require('node-http-proxy').createServer(8080, 'localhost').listen(80);

So thank the Nodejitsu's for the hard work, by downloading the latest code now.

Buffer floats and doubles

Commit e505a1215c5 lands supports from reading and writing floats and doubles to the buffer object. These changes will make it allot easier to handle binary data inside Nodejs and JavaScript. JavaScript already started implementing typed Arrays but buffer objects are much useful for Node at this point as they add allot less to the total heap size of V8. And there for allow you allot more memory than the 1.7 GB restriction on 64 bit machines (this is a v8 restriction). But also Buffer objects are send to the sockets much faster because it's easier for node to get the pointer to the raw data.

UPDATE: Thanks to the correction of @mraleph Nodes buffers are actually implemented on top the External Array API of V8. They have a different syntax, but they are basically the same thing.

Documentation