Re: POP3 "resume download" extension

At 09:06 PM 12/17/99 +0500, Bonatti, Chris wrote:


>Keith Moore wrote:
>
> > > Thinking about pipelining, though, how does this sound: POP3 is 
> normally a
> > > half-duplex-like dialog.  Suppose we allow an allowed a received command
> > > sequence (like maybe "!NEXT") to queue an interrupt of the download at
> > > the next chunk.
> >
> > If you're suggesting that servers do out-of-order command processing,
> > I don't think that's the way to go.
> >
>
>No, I didn't really mean out-of-order command processing.  What I meant is 
>that
>there would be a recurring state at the end of every chunk in which the server
>checks to see whether it has received an "interrupt" command.  If it has, it
>could skip to the start of the next message.  If it hasn't, it would continue
>with the next chunk.

So the client wouldn't request the chunks. The server would just send in 
chunks and look for aborts every once in a while.

If you're doing one RETR after another and you're pipelining you're going 
to have at least one command (a RETR) waiting at the in queue on the server 
to be processed. If you send an ABORT it will be behind the RETR in the 
queue so you'd have to process it out of order.

Processing out of order would be bad because it would make the server much 
more difficult to implement. POP servers can be very simple now.

Being able to request chunks with a RETR command would help aborts for long 
messages. It seems in an ideal chunked implementation the client would have 
some idea of the bytes/sec capacity of pipe is and only have requests for 
enough bytes to fill the pipe outstanding. That way you only wait on the 
order of one round trip for an abort. Since the size of a message is 
typically much larger than the number of bytes to fill the byte, chunking 
requests win.

How easy it would be to get to an ideal implementation is another matter. 
Pipes are very bursty and through put is hard to characterize. I suspect 
one would still be able to get much faster abort times with chunked 
requests without compromising overall download speed though.

LL