On Sat, 3 Feb 2007, Eric A. Hall wrote:
A robust mechanism only requires the server to know that the client
received the entire list of responses: if so then the client is not at
obvious risk of resending; if not the server can refuse to accept
responsibility on the grounds that the session was lost. So all we need is
a way for the client to send SOME KIND OF DATA, after the server has sent
the full list.
That just moves the problem; it doesn't solve it. With your suggestion, if
the client thinks it sent the next command but the server didn't receive
it then the message gets lost or duplicated. Remember that TCP APIs
generally don't allow an endpoint to discover on connection failure which
of the data that was passed to the stack was acked by the other end. TCP
is not reliable in the event of loss of connectivity.
My current design is somewhat thinner than that--if the server is able to
write() the final response code without error, then it should be safe to
assume that the client received the full list as well as the final
response and the mail belongs to the server now.
Absolutely not! This is exactly the RFC 1047 problem!
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
SOLE: NORTHEAST VEERING SOUTHEAST 3 OR 4. MODERATE OR ROUGH. FAIR. MODERATE OR
GOOD.