13

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.

boom
  • 10,856
  • 9
  • 43
  • 64
  • Why do you want to move to plain webSockets? – jfriend00 Jul 23 '16 at 21:34
  • 3
    Although this is off-topic, and provokes an opinion based discussion, I'm voting it up... I hope you'll get a good technical answer and that more people will learn about the (huge) difference between the platforms. – Myst Jul 25 '16 at 01:03

1 Answers1

24

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).

jfriend00
  • 683,504
  • 96
  • 985
  • 979
  • 2
    Middleware and Cookies aren't just a socket.io feature, they are common framework features that would probably be available also on other frameworks... besides, it has little (if anything) to do with the websocket layer and more to do with the http layer. I would suggest they be taken off the list. Having said that, nice answer... although I'd love more technical details on some of the stuff. – Myst Jul 25 '16 at 01:07
  • 1
    Number 1. is wrong. `socket.io` doesn't perform fallback to long polling. It actually performs a slow connect to Websockets, so it always starts by using XHR. – Myst Jul 25 '16 at 01:09
  • 3
    @Myst - socket.io does absolutely support long-polling if the browser does not support webSockets. And, you might want to understand that ALL webSocket connections start with a regular HTTP request (that has a few custom headers set in it). See http://stackoverflow.com/questions/31282578/why-is-my-socket-io-using-long-polling-instead-of-the-websocket for more info. In fact, socket.io supports multiple transports besides webSocket. Long Polling is one of them. – jfriend00 Jul 25 '16 at 01:49
  • 1
    @Myst - The middleware and cookies points are capabilities of the server-side socket.io library. If you use socket.io they are automatically included. They are not part of any webSocket specification so to have the equivalent, you'd have to find a webSocket library that also included them. To me, they are part of the benefits of using socket.io over plain standard webSocket which is what this question was about. – jfriend00 Jul 25 '16 at 01:51
  • 1
    @jfriend00 I know. I wrote a websocket server in C. socket.io always starts with long polling. It upgrades the connection to websockets at a later stage, so it isn't a fallback. Long polling is the default. Also, because all websocket connections start with HTTP, middleware and cookies aren't socket.io specific. – Myst Jul 25 '16 at 01:56
  • 1
    @Myst - Well, it depends upon the settings you use for the connection. You can ask it to start with a webSocket right away. I'll change my wording. I'm just saying that webSocket-specific middleware and access to cookies from any message are features of the socket.io library that are not in any webSocket library I've seen. If you use socket.io, you get those server-side features specifically for your socket.io connections in a way that is simpler than trying to use your http server's framework for the same functionality. It is a useful benefit of the socket.io library. – jfriend00 Jul 25 '16 at 01:58