4

We're using SignalR for real time pushing of messages, and I've read and realized that SignalR is not reliable, nor does it claim to be.

But everywhere I've looked, it never states where they don't claim to take responsibility for a lost message. Since WebSockets run over TCP, and TCP can (assuming no lost connection) guarantee delivery. What step in the process of receiving the message on a socket to being handled by the client is the "unreliable" part? I.e. where do I need to put my own reliability layer?

gwow12345
  • 311
  • 3
  • 12
  • Here is something I offered as a [possible solution](https://stackoverflow.com/questions/55897522/how-to-do-guaranteed-message-delivery-with-java-client-signalr/55902921#55902921) to a similar question. – Frank M Oct 16 '19 at 20:17
  • I appreciate your answer! Perhaps the question was not too clear, but we are looking to find where in the pipe of the messing from socket reception to being handled the unreliability "starts". We are experienced in putting in secure layers to make up for lacking features, but we are having trouble identifying where the implementation would best fit. We want to handle/detect lost messages as soon as possible. "Where" can I earliest detect a lost message? At consumption? Perhaps I can inspect a message before it is added to the SignalR queue (buffer)? Thanks again. – gwow12345 Oct 17 '19 at 08:50
  • I think that messages will be delivered reliably on an established connection. That should be guaranteed by TCP (it provides a reliable bitstream). But if the connection itself broke, then how do you know what message have already arrived at the recipient, and you would have to resend the lost ones (which are not recorded at the sender side). If you don't exactly know which messages to resend, the recipient also has to be fine with duplicate messages. – Markus Meyer Mar 14 '23 at 14:14

0 Answers0