I have created my own IConnectionIdGenerator
implementation which for simpicty in my webforms application names the client connection Id by the EmailAddress.ToLower() of the logged in authenticated user (if that’s not available then it defaults back a guid).
Calling the client from my page code behind all works fine.
hubContext.Clients[LoggedInUser.EmailAddress.ToLower()].updateProgress(i)
However it seems that if I open another browser or tab with the same logged in user both the foreverframe connection on both windows keeps giving a 301 result then a 200 result alternating and repeating.
I assumed that assigning the same connection Id would just give me an easy way to make sure messages correctly go to the correct user of the system no matter where they connected.
Do they always have to be unique and will I have to build another layer to manage connections to logged-in user accounts or am I missing a trick here?
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.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.