Client-server communication over SST - how server detect communication broken? And connection stability.

If I break the communication link, the client instantly knows via the SstDisconnectCallback.  But the server doesn't get the callback, even waiting hours.

If instead I use the Task Manager to kill the client, the server does get the callback.  I am no expert but I think this means that the server gets the callback only because something on the client machine actively sends something to the server, or something happens at the socket level.  Something that doesn't get to happen if I break the communication link (in my case, by terminating my laptop's VPN connection to the server).

Running tcpview, on the client machine I see ports being used including one to the server's port.  But on the server, tcpview shows no hint that the client is connected.  I am guessing this is why if the communication link is cut, the callback doesn't happen in the server.

So, what is the best practice for the server to deterministically know when the client is no longer there?  Having the client regularly ping the server, and the server knows the client is gone if it doesn't get a ping in a certain time?

We do have a second communication path in the opposite direction, say for the server at any time to tell the client to put up a popup.  The server could ping clients this way, but some customers have this lesser used communication path blocked.

The reason I was looking into this is because one of our customers is now using our client on client machines from their homes over VPN - due to COVID.  A few people have had an intermittent problem of the client losing communication with the server, where our client knows to exit.  Is there a better practice of when the client gets the SstDisconnectCallback, to try to reconnect for a while?  Unfortunately if that is done successfully, and our server has some enhancement and detected that the client went away - we wouldn't want the client to be able to reconnect and keep going where it left off.  The client would instead have to know it has to go back to the login screen.  I guess the main thing I am asking in this paragraph is a way to make client-server SST more fault tolerant.

Hi Wayne

we are using SST based on SstPingPongByReference for our client - server application. And we are monitoring the SST connections in both directions. The client application sends cycling heartbeat messages to the server using SST and polls the server using ping / ICMP. The server application checks the received heartbeats and sends cycling #sstPrintString to a client object. In case of losing connections the application is able to react, but I'm not sure about getting the SstDisconnectCallback in all cases. For the SST re-connecting to the server, the IP address of the server have to be ping-able.

And the application is running on a LAN only (WAN access by remote desktop connections)

Regards

Norbert