Moving from socket.io to raw websockets?

Question

Right now I'm using socket.io with mandatory websockets as the transport. I'm thinking about moving to raw websockets but I'm not clear on what functionality I will lose moving off of socket.io. Thanks for any guidance.

Answer 1

The socket.io library adds the following features beyond standard webSockets:

1. Automatic selection of long polling vs. webSocket if the browser does not support webSockets or if the network path has a proxy/firewall that blocks webSockets.

2. Automatic client reconnection if the connection goes down (even if the server restarts).

3. Automatic detection of a dead connection (by using regular pings to detect a non-functioning connection)

4. Message passing scheme with automatic conversion to/from JSON.

5. The server-side concept of rooms where it's easy to communicate with a group of connected users.

6. The notion of connecting to a namespace on the server rather than just connecting to the server. This can be used for a variety of different capabilities, but I use it to tell the server what types of information I want to subscribe to. It's like connection to a particular channel.

7. Server-side data structures that automatically keep track of all connected clients so you can enumerate them at any time.

8. Middleware architecture built-in to the socket.io library that can be used to implement things like authentication with access to cookies from the original connection.

9. Automatic storage of the cookies and other headers present on the connection when it was first connected (very useful for identifying what user is connected).

10. Server-side broadcast capabilities to send a common message to either to all connected clients, all clients in a room or all clients in a namespace.

11. Tagging of every message with a message name and routing of message names into an eventEmitter so you listen for incoming messages by listening on an eventEmitter for the desired message name.

12. The ability for either client or server to send a message and then wait for a response to that specific message (a reply feature or request/response model).