I have created my own IConnectionIdGenerator
implementation which for simpicty in my webforms application names the client connection Id by the EmailAddress.ToL
Yes thats perfect, I came to a simlar conclusion.
I also trying to think of a way to make client broadcast messages to the same email address group unique to the current url (so a progress bar on one page does not also update a progress bar on another)
I will either make extend the group id to be something like emailAddress + currentURL
so its just a combination of the two strings. However that would make any global site broadcasts (to all urls) difficult to do unless there is a way of getting the groups collection and parsing out the email addresses and sending the message to each email address + url combination.
It may be better if I just tag on some client side check and send a progress bar Id as a parameter that is unique to the progress bar on the page that is ment to be updated.
Connection ids have to be unique. If you don't make them unique then one will kick the other connection offline. Internally we use the connection id as a unique identifier for a connection and we disconnect dupes.
If you get repeated 301 responses it's likely because you have a folder in your app called signalr, and it isn't directly related to sharing connection ids.
I recently tried to do the same and experienced the same problems, so my conclusion is that the connection id must be unique, otherwise everything starts to fail with repeated 301 and 200 responses.
What I did to workaround this problem was to use the default GUID connection id and instead add the connection to a group which is identified by my own id (email address in your case) after starting the connection.
This way I can call Clients[emailAddress].doSomething()
and it broadcasts to all open tabs of this user.