Re: what to say on timeout?

----- Original Message ----- 
From: "Richard O. Hammer" <ROHammer(_at_)EarthLink(_dot_)net>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Sunday, January 04, 2004 10:47 PM
Subject: Re: what to say on timeout?


> But there is the 421 message which SMTP servers can send.  RFC 2821,
> Section 3.9 says:
>
>     An SMTP server MUST NOT intentionally close the connection except:
>  ...
>     -  After detecting the need to shut down the SMTP service and
>        returning a 421 response code.  This response code can be issued
>        after the server receives any command or, if necessary,
>        asynchronously from command receipt (on the assumption that the
>        client will receive it after the next command is issued).
>  ...
>
> It seems to me that timeout because of inactivity has some similarity
> with the circumstance calling for a 421 response code.  In both cases
> the server is going to terminate the connection.  If it is expected to
> send a response code asynchronously from command receipt in the case
> of forced server shutdown, why not in the case of timeout?
Because the client is not expecting it.

Unless I misunderstanding,  the above is based on the idea that the CLIENT
has already sent a command and is currently waiting for a server response.

I don't know if any internet client protocol, maybe with the exception of
FTP, where it can get a unsolicated server response.  A standard
client/server protocol state machine is simply not designed for this.
Clients are not going to wait around for something it is not expecting.  It
issues a command, waits for a response.  The client drives the server. Not
the other way around.

It is outlined like this:

         SendCommand("HELO")
                WaitForResponse()    // Synchronous concept
         SendCommand("MAIL FROM:")
                WaitForResponse()    // Synchronous concept
         SendCommand("RCPT TO:")
                WaitForResponse()    // Synchronous concept
         SendCommand("DATA")
                WaitForResponse()    // Synchronous concept
         SendCommand("QUIT")
                WaitForResponse()    // Synchronous concept

etc.  It is not an asynchronous concept such as:

         SendCommand("HELO")
                WaitForResponse()    // Synchronous concept

         CheckForAnyMoreServerResponse()    // /Asynchronous Concept
         SendCommand("MAIL FROM:")
                WaitForResponse()    // Synchronous concept

         CheckForAnyMoreServerResponse()    // /Asynchronous Concept
         SendCommand("RCPT TO:")
                WaitForResponse()    // Synchronous concept

         CheckForAnyMoreServerResponse()    // /Asynchronous Concept
         SendCommand("DATA")
                WaitForResponse()    // Synchronous concept

         CheckForAnyMoreServerResponse()    // /Asynchronous Concept
         SendCommand("QUIT")
                WaitForResponse()    // Synchronous concept

Now, if that is what is being suggested here, then that would completely new
to me and an odd, non-standard client/server design methodology.

The only thing close the above is maybe this:

         SendCommand("HELO")
                WaitForResponse()    // Synchronous concept

         CheckForSocketAlive()    // /Asynchronous Concept
         SendCommand("MAIL FROM:")
                WaitForResponse()    // Synchronous concept

         CheckForSocketAlive()    // /Asynchronous Concept
         SendCommand("RCPT TO:")
                WaitForResponse()    // Synchronous concept

         CheckForSocketAlive()    // /Asynchronous Concept
         SendCommand("DATA")
                WaitForResponse()    // Synchronous concept

         CheckForSocketAlive()    // /Asynchronous Concept
         SendCommand("QUIT")
                WaitForResponse()    // Synchronous concept

Which can be already done at the SendCommand() with an implicit socket close
error on the send() command.

Right?

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com