Given:
- Internet and system requirements to work 24/7, every day network breaks from the provider, etc.
- the server must regularly check the connection in order to quickly detect a break and remove the client from the list of available
- the client must regularly check the connection in order to quickly detect a break and begin attempts to reconnect to the server

Without any hesitation, I solved the problem head-on - I made two separate “circuits” of heartbeats, one for the client, the other for the server. If you throw away the rest of the logic, the scheme is as follows (top - chronology, bottom - client algorithm and server algorithm): enter image description here

But what happens? Every N seconds (sleep is not shown in the picture, but it is there and there), four packets are sent over the channel — a bit too much. And the algorithm turned out quite confusing.

Is it possible to somehow simplify the scheme, limiting only two packages?

  • heartbeat doesn't need an answer - etki
  • one
    ... and if, besides your heartbeat, something is regularly transmitted through the channel, then the heartbeat itself is not needed, if in the last N seconds something was transmitted through the channel: you can count down the time for the next heartbeat to be transmitted not from the previous one, but since the last successful data transfer, as a result, you will only be sent a heartbeat when no one has communicated on the channel for N seconds. And this means that the channel and the machine are not loaded, and there is nothing to worry about loading them, no. - etki
  • You can be limited to activity on one side only, for example, a server. So the client, having received the packet from the server, makes sure that it is alive, and the server, in turn, receiving a response, realizes that the client is alive. By the way, you probably know that, in addition to the main stream, the tcp connection can independently transmit the stream, so-called out-of-band (Urgent) data (the MSG_OOB flag in send() and recv() calls, more details in man 7 tcp ) , which is probably more convenient for the implementation of heartbeat, since in this case the heartbeat data will not interfere with the main exchange - avp
  • @Etki "on heartbeat do not need an answer" Yes? Then how can I understand that everything is fine with the connection and send the next heartbeat? I looked at the standard keepalive, it also seems to have something like an answer ................. "and if you have something other than heartbeat, it is regularly transmitted via the channel" I can for weeks Nothing is transmitted through the channel - KG
  • one
    Not. Simply, each of the parties should immediately set a timeout for receiving heartbeat data and reinstall it upon receipt of data. The client receives the request, the server responds. Got, reset timeout. About Windu and apples will not lie, google. The idea should be. - avp

0