Guaranteed delivery in SignalR

Question

I\'m evaluating SignalR for a medium-load web application.

We\'re expecting ~500 msgs / sec, which shouldn\'t be a problem with SignalR.

However, we\'re worried

Answer 1

One fairly easy way to handle this would be to assign each message an ID that increments with each message. The client would need to keep track of the latest message that he'd received, and upon reconnection would just send that message ID to the server; and the server would then need to send all the missed messages down to the client. Should be reasonably simple to implement.

EDIT: I don't think you'd have to maintain any real state on the server proper - I think almost all of it could get pushed out to your datastore or to your client. The client would send up the ID or timestamp of the last message that it had received:

$.connection.myHub.server.updateMe(lastMessageId);

You'd want some sort of backing datastore - so when the server receives the updateMe() message, it would do a query on the database and pull out all the rows with an ID greater than the one it just received. It would return those to the client as part of the return value of its UpdateMe() method. And then it would try to deliver any new messages that come along the same way it normally would, by calling methods on the client.

As for statelessness being a goal of SignalR: I can't comment on that, beyond observing that I can't imagine any reasonably complex real-world application that wouldn't need to do have some sort of backing datastore, whether it's on SignalR or some other framework (WCF, XSockets, etc.) makes little difference.