[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

pipelining/BDAT



Matti Aarnio <mea@nic.funet.fi> writes:
>         Yes, but WHEN to drain the round-trip of inputs, and replies ?
>         The basic PIPELINING says it happens with DATA command,
>         but how to do it with BDAT ?  It would not make sense to feed
>         100 kB to the recipient just to sync the status reports of the
>         envelope...

With DATA, the client must stop sending commands and drain its input
of replies before sending the message data.  With BDAT, there is no
point in the transaction at which the client must do this.  A client
could, for example, deliver two or more small messages in one round
trip.

If it is probable that at least one recipient is good, it does make
sense to feed 100kB to the server before receiving the replies to the
RCPT commands.  You have to weigh the cost of waiting for the round
trip times the probability that one RCPT will succeed versus the cost
of transmitting the message data times the probability that all RCPT
commands will fail.  You will probably notice that in practice, there
is a high probability that at least one RCPT command will succeed.

The best way to do this is to put the SMTP socket in non-blocking
mode.  Write out as many commands as you can.  When writing output
would block, use select() to wait for either output to drain or input
to arrive.  As select() indicates that data is available for reading,
get it and parse the replies.  If you parsed a 4xx or 5xx reply for a
BDAT command for a message you are currently writing out, you set a
flag which causes the rest of the BDAT chunks to be skipped after the
current BDAT chunk has finished writing out.

>         Nope, Mr. Vaudreuil is the author.

But I know Ned has implemented CHUNKING.

-- 
_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up