At 12:56 PM +0000 2/23/06, Tony Finch wrote:
The BURL spec requires a sync point after the "LAST" BDAT or BURL command,
instead of after the message envelope. I think it would be better for BDAT
and BURL to not require any synchronization at all: if the client wants a
sync, it can use the NOOP command. Note that the main reason a sync point
is required after DATA is so that the client and server agree about
whether the next utterance from the client is a command or is message
data. This isn't a problem for BDAT because the command and data are sent
together, with a single response from the server for both.
This would allow a client to pipeline multiple messages together, which
means you can move from using TCP in interactive mode to bulk data mode,
and therefore make the best use of the available bandwidth. For example,
consider a 1Mb/s link with a 100ms RTT. If the client sends a 5KB message,
this takes about 50ms to transmit, so by the time the server's replies
arrive the client will be one or two messages further on; if there was a
problem, the client can deal with it asynchronously, and it will have done
50ms extra useful work. If the client sends a 20KB message, the server's
replies will start arriving part-way through message transmission, so if
there is a problem the client can usefully RSET it before the next chunk
to save time and bandwidth.
I think it would be cool to allow this kind of high-bandwidth asynchronous
message transmission. It is also more friendly from the point of
congestion control than having multiple concurrent SMTP connections
perpetually in TCP slow start.
Interesting. Both mobile and desktop clients often send multiple messages.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
"The meat is rotten, but the booze is holding out."
--alleged computer translation of "The spirit is willing,
but the flesh is weak."