Menu
I would like a user to retrieve messages that they may have missed when they re-connect to the Signalr server.
I know I could persist the messages independently of Signalr, keep track of the last message id received in the client and resend the newer messages on reconnect but I was looking at the SqlServer backplane's Messages_0 table which has a Payload and PayloadID and was wondering if there is a more Signalr'y way to get the backplane to do this for me or to extend the backplane to do this for me.
Do you any ideas how I might go about this?
278
reconnecting(function() { notifyUserOfTryingToReconnect(); // Your function to notify user. }); Handle the disconnected event to display a message when an attempt to reconnect has timed out.
To test reconnect after the server goes down use iisreset. To simulate client connection dropping (good luck) pull the network cable :) Pulling the network cable won't accurately simulate a client connection dropping when you're using Azure SignalR Service.
SignalR doesn't guarantee message delivery. Since SignalR doesn't block when you call client methods, you can invoke client methods very quickly as you've discovered. Unfortunately, the client might not always be ready to receive messages immediately once you send them, so SignalR has to buffer messages.
Timeout configuration for SignalR can be set in Application_Start method of Global class in Global. asax. cs file. // Wait a maximum of 30 minutes after a transport connection is lost // before raising the Disconnected event to terminate the SignalR connection.
SignalR is more of a real time message system used to broadcast a request to connected clients. There isn't a built in way to track that the broadcasted message was retrieved by a particular decoupled client if you were sending to many clients. Service bus/queue mechanisms are more suited for that IE - MSMQ, Rhino Service Bus, RabbitMQ etc. You can definitely build a queue that handles the requests and keeps an eye on which identities are still connected to a hub and have SignalR handle the broadcasting portion of the communication and if an identity decouples and comes back to a group resend only to that identity.
The only thing about going a pure service bus method is that a client would have to have the protocol set up properly on their machines such as MSMQ needing the MSMQ Server Core Integration, which adds to the complexity of deploying.
150
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
