Socket.IO - Internals

Fallbacks

Socket.IO has a lot of underlying transport mechanisms, which deal with various constraints arising due to cross browser issues, WebSocket implementations, firewalls, port blocking, etc.
Though W3C has a defined specification for WebSocket API, it is still lacking in implementation.
Socket.IO provides us with fallback mechanisms which can deal with such issues. If we develop apps using the native API, we have to implement the fallbacks ourselves. Socket.IO covers a large list of fallbacks in the following order:

• WebSockets
• FlashSocket
• XHR long polling
• XHR multipart streaming
• XHR polling
• JSONP polling
• iframes

Connection using Socket.IO

The socket.io connection begins with the handshake. This makes the handshake a special part of the protocol. Apart from the handshake, all the other events and messages in the protocol are transferred over the socket.
Socket.io is intended for use with web applications, and therefore it is assumed that these applications will always be able to use HTTP. It is because of this reasoning that the socket.io handshake takes place over HTTP using a POST request on the handshake URI(passed to the connect method).

Events and messages

WebSocket native API only sends messages across. Socket.IO provides an addition layer over these messages which allow us to create events and again helps us develop apps easily by seperating the different types of messages sent.
The native API sends messages only in plain text. This is also taken care of by socket.IO. It handles the serialization and deserialization of data for us.
We have an official client API for the web. For other clients such as native mobile phones, other application clients also we can use socket.IO using the following steps.
First, a connection needs to be established using the same connection protocol discussed above.
Second, the messages need to be in the same format as specified by socket.IO. This format enables socket.io to determine the type of the message and the data sent in the message, and some metadata useful for operation. The message format is:

[type] : [id ('+')] : [endpoint] (: [data]

• type is a single digit integer, specifying what type message it is.
• id is message ID, an incremental integet used for acknowledgements.
• endpoint is the socket endpoint that the message is intended to be delivered to.
• data is the associated data to be delivered to the socket. In case of messages, it is treated as plain text, for other events, it is treated as JSON.