[Top] [All Lists]


2006-03-06 16:57:31

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."

<Prev in Thread] Current Thread [Next in Thread>