Support for multiple servers without the need for 'sticky sessions'

[ctangell]

Is your feature request related to a problem? Please describe.
We have multiple servers that are behind a docker swarm load balancer. Our problem is that we have many requests coming in from one client (as opposed to many clients making single requests) so we split the load from one client going to different servers. We would like to use web sockets to communicate back to the client occasionally after specific requests come in. Those communications would need to be able to come from any of the servers, depending on which instance actually handled the initial request.

Describe the solution you'd like
We would like to have flask-socketio support multiple server instances without the need for 'sticky sessions', i.e. to share the socket connection among multiple server instances.

Describe alternatives you've considered
We have considered:

1. using 'sticky sessions' (i.e. ip hashing in the load balancer) but have not done this because that would require hard-wiring in routing to a specific number of servers from an nginx front end to the flask servers, and we need to be able to scale up and down the number of workers easily, and it would put too heavy a load on any single server.
2. We have also considered forgoing websockets and just storing state in a redis store and have the client periodically poll the redis store through an additional api to get the information we'd like to send to the client. This is undesirable because we can't guarantee when that information will be updated.

Additional context
We currently do session management to cookies but are able to consider using flask-session and a redis store.

[miguelgrinberg]

I am unlikely to ever implement this, because sharing the client sessions is extremely inefficient and is going to adversely affect performance for the vast majority of users who do not need this.

I recommend that you drop long-polling and only use WebSocket. With only WebSocket there is no need to sticky sessions because each client sends a single request to establish the connection.