I have a TCP server to check the connection status of broadband equipment. When the equipment (CPE) boots up, it establishes a connection with this TCP server.
Subsequently, the server and the equipment continuously exchange ping and pong messages in XML format to confirm that the equipment's connection is ongoing.
However, I have a question here. Handling a TCP server is new to me, so I created a simple server and client to test it. When I terminate the client program, I notice that the TCP server immediately disconnects as well.
If there's a power issue with the equipment, a network problem, or if the equipment intentionally disconnects, the TCP server can determine a disconnection even without exchanging ping-pong messages.
So, why am I exchanging ping-pong messages while consuming unnecessary resources? Is it possible that due to network issues or other factors unknown to me, the equipment's network might face problems and the connection with the server should disconnect, but the server fails to receive the disconnect signal?
If that's the case, then the current method of checking through ping-pong for the server seems justified.
When you terminate the client program, it (or the operating system) has the opportunity to send the server a FIN packet and do an orderly shutdown. There are scenarios where that won't happen: pulling the network cable, losing power, your ISP failing, etc. Those conditions can be detected by sending periodic heartbeat messages and timing out the connection when too many are missed.