Replace ConnectionManager.MakeNewConnectionId() with a pluggable id generator (and a discussion about SignalR Cluster)

[KPixel]

The general idea is to make the ConnectionId into a vessel of useful information (think: JWT).

This suggestion goes with #683 to improve the following scenario (and many others):

Currently, a SignalR cluster using RedisHubLifetimeManager looks like this:

When S1 (server 1) wants to send a message to C2 (client 2), it sends the message to Redis, which broadcasts it to all servers, and S4 is the only one to use that message and send it to C2.

If we can include a server id inside the ConnectionId, then S1 can know (without a lookup to a central database) which server to route the message to. We get something like this:

By the way, Redis itself has a similar mesh topology in Cluster mode. So, the message actually goes through more hops in that case. You can read more about the Redis Cluster Bus.
Edit: A Microsoft Orleans cluster is also similar to this design.

With this feature, we can implement #683 by grouping the connectionIds by server, and forwarding a single message to each server for its connections.

Practically, this new HubLifetimeManager could be built on top of something like Azure Service Fabric or containers. And I even thought about using SignalR for the communication intra-server...

But the whole point of this issue is to enable this scenario, not to actually build it.

[davidfowl]

Sounds like a fine addition. Connection ids can't be reused but making it pluggable seems completely reasonable.

[davidfowl]

Closing in favor of #604

[KPixel]

For anyone who is interested in the cluster scenario, please read #961 (just a starting point solving the need for a custom ConnectionId).