centiservice/matssocket

WebSocket-based server and client libs for asynchronous, bidirectional interaction with Mats3 from end-user clients

matssocket's Issues

MatsSocket: Serverside: Make all incoming message handling async

Handling of ACK/NACK and ACK2s should definitely be async.
But also handleSendRequestAndReply(..). If this does not get DB access, it can send RETRY back to client.

MatsSocket: Enable to provide state object from handleIncoming to adaptReply

A situation came up where it would be nice to have a state object traverse from the handleIncoming to adaptReply. This is already possible by using traceProperties, but it came up quite fast when developers started using this, so add it directly in the API. Overload forward methods to also have a state object, which is simply added to the existing state object that the library uses.

NOTE! Must think about how this ends up with SpringConfig "@Class"-variant. One might want to have the handleIncoming, the mats endpoint and its stages, and the replyAdapter, all share the same state object: An instance of the class it is defined on.

MatsSocket: Way for services to also be able to add "meta info", "debug info" to the reply.

If a MatsSocket only performs subscribe, no other message sending, then sub was never sent to server

The problem was that the "SUB" message was not considered "information bearing", and thus the MatsSocket would never open and connect.

This was probably not a big problem in actual usage scenarios as one probably very seldom would only subscribe, but also at least send a "what is the latest news"-type message. However, it nevertheless it caused some developers to use a considerable time on debugging why they never got any published messages from the server.

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

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.

MatsSocket: Make "self-healer".

If we lose DB-connection, we cannot forward messages anymore. The "MessageToWebSocketForwarder" will then bail, and hope for the self-healer to pick up when the DB comes back up, i.e. check if there are outstanding messages for live sessions (the self-healer handles sessions on its own node), and forward them.

Think together with centiservice/mats#115.

Server debug flags should be explicitly set

Currently, the server uses whatever was last sent over (with a default of zero on both client and server). This is pretty annoying if you want debug on a particular request: After this request, the server will use this for any server initiated messages (server-to-client send and request). Thus, you will always have to basically send a dummy "reset" message afterwards. This effectively makes the ability to set debug options in the config object meaningless..

It would have been better if this was more explicit. One thought was to just use whatever was set on MatsSocket.debug at startup to be the server-to-client debug flags. However, this makes it impossible to set any other "in runtime", i.e. if you have an app, and want to turn on the server-side debug flags (using some admin config screen), you'd have to restart the MatsSocket.

It would be better if this was an explicit setting, preferably so that when setting it on the client, it was immediately sent over.

I am thinking a property with setter action. And renaming "AUTH"-type messages to "CONF" or something, so that one can use it for multiple such client-server and server-client comms which are only for the messaging layer, not user comms.

MatsSocket: Client: add "magic endpoint" MatsSocket.initiations and .pings

Replies with all the InitiationProcessedEvents and PingPongs, respectively - and then deletes the lists on the Client (so that you can request them repeatedly).

The idea is then that the Server may do a request for this information if it wants.

MatsSocket: matsSocketServer.disconnect(userId)

The "disconnect" is useful to force re-authentication: When the MatsSocket restablishes WebSocket, it will do initial authentication.

MatsSocket: Add more MDCs, structure better.

MatsSocket: Handle RETRY in MatsSocket.js

... only relevant for Client MatsSocket.js when handling messages from Server, that is Server says "RETRY" to Client. The other way is not relevant, as Client won't ever say "RETRY" to Server - so there is no test other way.