On 1/4/2004 11:33 PM, Hector Santos wrote:
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.
By default, SMTP sessions follow a synchonous state path, which further
consists of synchronous, half-duplex transaction pairs (the <CRLF> and/or
'.' at the end of input is essentially a Go-Ahead signal). Pipelining
partly allows the transaction pairs to be full-duplex, but does not
otherwise affect the synchronicity of the transaction pairs or the overall
state machine.
As was pointed out already, IMAP allows full-duplex, asynchronous
transaction pairs (although its less common than might be expected in
practice, due to certain implications with the transaction structure)
while the overall state path for IMAP sessions are still synchronous.
A better example of this can be seen in negotiated TELNET, where the
end-points have to progress through an ordered state path, but can do
whatever they want whenever they want as long as the transaction is legal
within the context of the current state. An even better example of this
can be found in TCP itself.
Regardless, end-points must be prepared to receive unexpected data and
react accordingly. At the very least, an end-point should be prepared to
find unexpected data whenever the input is read.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/