[RFC] multi_ack protocol v2

Hi,

the fetch-pack/upload-pack protocol as of now goes like this:

- server sends the refs it has, then an empty packet
- client sends what it wants, then an empty packet
- client sends a rev-list via "have" lines in the hope to find a common
  rev. Interspersed, it sends empty packets.
- server answers to those empty packets with a NAK message, until it
  receives a "have" line for a commit it has (and which is therefore a
  common commit). This is answered by an ACK message, and no NAK or ACK is 
  sent after that
- client sends "done"
- server only responds if no common commit was found, with a NAK
- server sends pack

after thinking about my earlier approach, I think there's a better, less 
intrusive, and all in all just simpler approach:

- client asks for multi_ack protocol by sending " multi_ack" at the end
  of at least one "want" line
- server appends " continue" to the ACK message, but continues sending
  ACK (but not NAK) messages
- after receiving "done", server repeats last ACK message without 
  " continue" appended

After much fun with non-working, fragile code which had to be retracted 
from master, I hope that this approach is less prone to errors.

Note that this is incompatible to the multi_ack protocol I described 
earlier, but given that my patches were buggy anyway, I'd say it does not 
matter at all.

Thoughts, comments, objections?

Ciao,
Dscho

Johannes Schindelin writes:

after thinking about my earlier approach, I think there's a better, less 
intrusive, and all in all just simpler approach:

How many round-trips does it take?  When you're on the other side of
the Pacific from the server you care about round-trips. :)  One of the
nice things about rsync is that it does everything with only 1.5
round-trips.

Paul.

Hi,

On Thu, 27 Oct 2005, Paul Mackerras wrote:

Johannes Schindelin writes:

quoted

after thinking about my earlier approach, I think there's a better, less 
intrusive, and all in all just simpler approach:

How many round-trips does it take?  When you're on the other side of
the Pacific from the server you care about round-trips. :)  One of the
nice things about rsync is that it does everything with only 1.5
round-trips.

The plan is to reuse the existing framework. It sends 32 "have" messages, 
then a flush, then again 32 "have" messages, flush again, then reads all 
answers until a "NAK". The last 3 steps are repeated over and over again.

That means that there are always at least 32 "have" messages on the wire 
(which is described in the source code as "one window ahead"), i.e. it is 
about 32x faster than simple "have" -> "NAK/ACK" handshakes.

Ciao,
Dscho