Re: [RFC/PATCH 0/3] protocol v2

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 3, 2015, 17:13 UTC
Message-ID: <xmqqk2yy80mq.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150303103351.GA4922@lanh>

Duy Nguyen <pclouds@gmail.com> writes:

> Junio pointed out in private that I didn't address the packet length
> limit (64k). I thought I could get away with a new capability
> (i.e. not worry about it now) but I finally admit that was a bad
> hack. So perhaps this on top.

No, I didn't ;-) but I tend to agree that "perhaps 4GB huge packet?" is a bad idea.

The problem I had with the version in your write-up was that it still assumed that all capabilities must come on one packet-line.

The immediate issue that limitation in the current protocol we had was that the usual "we can help newer programs to operate better while getting ignored by existing programs by sending optional information as part of the capability advert" would not work for "upload-pack" to enumerate symrefs and their targets to help "clone".

The lesson to draw from that experience is not "we should have an option to use large packets". 64kB is plenty but the senders and the receivers have a lot lower limit in practice to avoid harming latency (I think it is like 1000 bytes before both ends agree to switch talking over the sideband multiplexer). It is not "we should anticipate and design protocol better", either. We are humans and it is hard to predict things, especially things in the future.

The lesson we should learn is that it is important to leave us enough wiggle room to allow us cope with such unanticipated limitations ;-).

My recollection is that the consensus from the last time we discussed protocol revamping was to list one capability per packet so that packet length limit does not matter, but you may want to check with the list archive yourself.