MatsSocket: "pub/sub"-style unreliable topic-based messaging Server-to-Client

[stolsvik]

For certain usage scenarios, it would probably be nice if the client tells the server which "channels" it wants to listen to, and the server keeps a tab of which clients wants which channel messages. This would only be in memory, and purely a best-effort style delivery.

Backend, it would use a Mats topicTerminator. It would keep a Map<String:channelName, Collection>.

The client "registers" such listeners, and each time it connects, it would forward over this list. The server then registers them in - and when it gets such a message on the relevant topicTerminator, it'd simply iterate over them (can do this multi threaded) and forward over the message.

If the client is not hooked up (yet) when the message goes, the he does not get it.

If the server reboots, all clients will have to reconnect. In a multi node setup, the new connection would probably come in a different node that still is connected.

To keep a bit of "reliability" here, the server could keep a list of the 5 minutes worth of messages sent for each channel. The server-side initiator would tag the message with its timestamp, and a random unique Id. When the client reconnects, it would send the timestamp of the last message received. It would then get all messages from-and-including that timestamp. If it cared about double deliveries, it would keep an "inbox" of messageIds that it has received, and filter based on that. (This list could be culled by timestamp).

Since it is the different nodes that will tag the messages with timestamp (such that they are equal when in the lists of the websocket-holding nodes), you can get "last timestamp" jumping back and forth. This must be taken into consideration when doing reconnect-resends. Maybe also store the received timestamp on the websocket-holding nodes - then when the client says "since this timestamp", the server would look up into its list, check all messages that has that "initiatedTimestamp" or later, then of these find the earliest "receivedTimestamp", and then use this earliest receveidTimestamp to filter which messages to resend over.

[stolsvik]

Note: Client side is done. Lacking replay of lost messages, and thus also telling the client that "sorry, mate, you lost messages". Also lacking testing.