detecting the close of a tcp connection

[Martin Draper]

I am running down a number of problems with my prototype mailserver. The problems come from the distant mail server droping the connection unexpectedly.

The most common problem is when the RCPT TO is sent to certain servers I get error 550 and the server drops the connection. Basically the connection is rejected by the server normally due to some kind of blacklist. They are supposed to complete the email sequence to properly then close the connection. Instead they simply drop the connection from their end which causes a series of errors while my server tries to complete the sequence from this end

Is there any way to to see if the connection has been closed other than waiting for an error from the connection.

[Michael Mattias]

Instead they simply drop the connection from their end which causes a series of errors while my server tries to complete the sequence from this end

I could not find any kind of 'event' functions to tell you this; all I could think of was doing the TCP equivalent of a "ping" on a periodic basis.

But I discarded that idea when I realized that a dropped connection should not be cause for "a series of errors" .. instead, whatever call fails or times out should should be handled in your code as soon as it happens and your application is responsible for "cleaning up" whatever needs cleaning up when a call fails.

(Code not shown.)

MCM

[John Petty]

550 is a very general error, can be as simple as "recipient not known", depends if you are hoping for more info. I think you will find that most SMTP servers will be quite happy (expect) if upon receiving that message you just clean up and discontinue the session.
If you do try to continue with another TCP SEND then you have to wait for a TIMEOUT error 24 the duration of which will depend on your initial setting in TCP OPEN. As per the manual TCP SEND is a "blocking" statement so control will not be returned to your program until either the receiving server has accepted the packet or ignored it thus giving a time out (that is the difference between TCP and UDP). This, depending on your settings, can be quite a long time causing problems if you are handling multiple connections. If you wish to persue that direction then each connection should be in its own thread so as to not cause problems with other connections.
PS of course your mail server also needs to be able to handle and clean up from incoming connections that disappear for no obvious reason, there may have just been a computer failure at the sending end.