Improve Documentation around Using Socket.IO with multiple nodes

[chill-cod3r]

I would like to see the documentation expanded around the following:

It makes it sound like there being no fallback to polling is such a horrible thing, however I don't see a lot of concrete examples of what that means. Based on additional research, it seems to mean the following:

• won't support IE < 10

What else am i missing / what implications are there in terms of this? It also hints that if you don't care about polling you should use another library instead, but I don't feel like that's a solid reason, especially if you're already familiar with socket.io and how the middleware and connection authentication works.

There is also an additional part of the documentation that mentions "living dangerously" if you only use websocket transport, but again I don't feel like it explains why?

it mentions a socket connection failing due to a few reasons, however, what are other implications if any of this? What's wrong with requiring people to connect through the websocket protocol? How common is it (or at least give a more concrete example of a use case) that if you don't allow polling as a transport option a certain subset of people won't be able to use your app?

I'm opening this issue to have this discussion, learn the answer to my question, and then am 100% willing to update the documentation to provide more concrete examples of the points in question if that's acceptable.

Thanks!

[darrachequesne]

@wolfejw86 to my mind, the main feature of the project is to be able to connect through Websocket in the best case, and to fallback to long-polling for older browsers or for users behind a misconfigured proxy. At least that's what's lead to the birth of the project in 2011, if I'm not mistaken.

What is meant by that part of the documentation (but that could indeed be clearer) is that disabling long-polling is a bad solution to two main issues:

• long-polling requires a way for users to always be redirected to the same node (sticky-session), or you will get HTTP 400 errors when reaching a new node (no such problem with websocket)
• long-polling connection is established first, and then upgraded to Websocket (which might give a sense of "slowness" when establishing the connection, and also requires sticky-session)

And that, in that case, the users should rather use raw Websocket instead of adding a dependency which adds some notable weight to the bundle and some overhead in the messaging.

[chill-cod3r]

I understand. So the point being "right tool for the right job" argument. As in:

• if you don't need to support a long-polling to websocket upgrade connection strategy or don't have the ability to support a sticky session, then this library is not the right tool for the job because you don't have a need to support that behavior and can get by with a much more minimal code dependency.

• if however you choose to use it anyways, there's not really anything wrong with it, other than it's a much larger code dependency that you're not using as much of

Does that sound right?