Re: ADTPro beta - protocol change

["schmidtd" <schmidtd@my-deja.com>]

On Apr 2, 1:37 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> Because this changes the protocol, could I suggest another?
>
> Since, once communication is established, it tends to be pretty
> solid, and since missing packets can now be detected by block
> number discontinuity, how about replacing ACKs of correctly received
> blocks with NAKs of missing or incorrectly received blocks?
>
> This would reduce the reverse traffic to practically nil without
> damaging reliability.
Glenn Jones and I have talked about a similar change where the server
blasts a buffer-full of blocks, then the client sends back a bitmap of
blocks it still needs to complete the buffer.

The current state of affairs uses the return trip as a pacing
mechanism.  The client uncompresses and checksums each block after it
receives it, then sends the reply when it's ready for the next one.
So there's a bunch of processing that happens in between - and would
get overrun without that pacing.

We can't keep the current processing model and just change the
protocol; it would require a fairly big processing change to defer the
decompression and feedback.  Another thing to watch out for: a 256-
byte half-block can actually expand by another 50% or so in the worst
case with RLE encoding, so we have not-quite-deterministic space
available in the buffer when staging the received data.