Closing a TCP/IP component connection the right way

[rlebeau]

What happens if one side of the connection doesn't send a quit type of message but just disconnects?

Are you asking about the client side or the server side?

On the server side, you will still get an OnDisconnect event triggered. That is not dependent on any bye/quit message.

On the client side, nothing will happen unless you try to read/write data after the disconnect occurred, in which case you will then get an exception, such as EIdConnClosedGracefully (if the disconnect is graceful and intentional) or EIdSocketError or similar otherwise.

or the connection is lost (eg isp failure, ethernet cable gets yanked out the wall etc) ?

Nothing will happen until the OS deems the connection is actually lost and starts reporting errors on it, which can take time. Until then, the connection is just sitting idle. Remember, TCP is designed to survive outages and recover from them when possible.

So, if you try to read data on a connection that is in this state, it will simply drain the InputBuffer as normal until it can't satisfy further reads, and then it will wait on the socket until new data arrives or an error occurs.

And, if you try to write data, it will continue to be buffered inside the socket as normal until the buffer is full, at which time the socket will block further writes until the OS flushes the buffer or an error occurs.

Does OnDisconnect() still get triggered?

On the server side, yes (eventually - consider using read timeouts or TCP keep-alives to lower the time needed to detect lost connections).

On the client side, the OnDisconnect event is not asynchronous. It is simply triggered when the app explicitly Disconnect's the client while it is still in an open state.