0

I'm going to share an example where I noticed this and would like to know if there is a known pattern of why one would do this.

I have two instances of rsyslog running on different machines. One acts as a receiving server, the other as the sending client.

While there is a connection the following is seen on the server:

receiving-server$  netstat -plant4 | grep 192.168.101
tcp        0      0 192.168.101.180:80      192.168.101.14:50070    ESTABLISHED 4925/rsyslogd

After that a stopping of the client service is triggered:

sending-client$ systemctl stop rsyslog
receiving-server$  netstat -plant4 | grep 192.168.101
tcp        0      0 192.168.101.180:80      192.168.101.14:50070    TIME_WAIT   -              

The TIME_WAIT is a state that happens on the side which initiated the connection termination ref.

TIME-WAIT - represents waiting for enough time to pass to be sure
the remote TCP received the acknowledgment of its connection
termination request.

This means that the client is telling the server initiate closing the connections because that same client is stopping. Why wouldn't the client just close the connections?

Why does the complexity of adding another "closing protocol" on top of TCP makes sense as a design choice?

2
  • 1
    Not to be glib, but good communication is polite. I can see how it might be useful to a server to get a message from a client to the effect of "I'm stopping, so you might want to take some action accordingly." Commented May 21, 2019 at 16:17
  • Seems like I'm getting close votes with the reason Questions asking for assistance in explaining, writing or debugging code. My perspective is that this is a requirements, architecture, and design question asking why would you introduce another layer of protocol given what TCP offers already. Updating the question. Commented May 22, 2019 at 8:23

1 Answer 1

3

This process ensures all parties - client and server - have the same information about the connection state, and is generally in keeping with the design principles of TCP as opposed to UDP.

Without this, what can happen is that a client either stops a connection, or sends a message that it is stopping and that message gets lost, so you end up with a client that thinks the connection is terminated and a server that is thinking the connection is still open. The server can't confidently free-up resources associated with this connection without possibly terminating valid connections without proper notification, and may end up trying to send messages to the client - only to wait for them to time out or be rejected.

Shutting the connection abruptly would be rather selfish of the client, and part of the design of TCP is not to privilege one side of a connection or the other, and to generally make sure every message arrives as expected, and further that the sender knows the message has arrived (thus the acknowledgement).

Doing things the way you've observed ultimately ensures all parties to a communication transparently hold the same information about the state of the connection, and if one party wants to close the connection then they can be sure the other party knows this. In practice this may not be important to you in any given use case, and you still need ways to detect and handle dropped connections (such as with timeouts).

This tends to matter most when some important action should be taken on a closed connection. This could include changing the state of the user (setting them to offline in a messenger app, removing a player from a virtual world, etc), freeing up resources for others to use right away (restricting streaming to a certain number of simultaneous users), discarding temporary encryption keys or otherwise cleaning up state information that only applies to that single connection, etc.

1
  • ... or sends a message that it is stopping and that message gets lost, so you end up with a client that thinks the connection is terminated and a server that is thinking the connection is still open. In this case why can't the same happen just with inverse roles? Or does the initial client's message for the server to close the connection now allows the server to safely abruptly terminate the connection (it knows the client wanted a close anyways) Commented May 21, 2019 at 23:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.