Re: [PATCH 6/6] remote-curl: ensure last packet is a flush

[Jeff King <peff@peff.net>]

On Mon, May 18, 2020 at 09:34:42AM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > On Fri, May 15, 2020 at 05:02:45PM -0400, Denton Liu wrote:
> >
> >> On Wed, May 13, 2020 at 02:04:58PM -0400, Denton Liu wrote:
> >> > This is not a complete solution to the problem, however. It is possible
> >> > that a flush packet could be sent in the middle of a message and the
> >> > connection could die immediately after. Then, remote-curl would not
> >> > error out and fetch-pack would still be in the middle of a transaction
> >> > and they would enter deadlock. A complete solution would involve
> >> > reframing the stateless-connect protocol, possibly by introducing
> >> > another control packet ("0002"?) as a stateless request separator
> >> > packet which is always sent at the end of post_rpc().
> >> > ...
> > I do kind of like the idea of a stateless separator packet, if I
> > understand your meaning correctly. I'll wait to see what the patches
> > look like. :)
> 
> I vaguely recall talking with somebody (perhaps it was Shawn Pearce)
> about my long-time complaint on the on-the-wire protocol, in that
> the protocol sometimes uses flush to merely mean "I've finished
> speaking one section of my speech" and sometimes "I've done talking
> for now and it's your turn to speak to me" (the receiving end needs
> to know which one a particular flush means without knowing the
> context in which it is issued---which makes it impossible to write a
> protocol agnostic proxy.  
> 
> If the above proposal means that we'll have an explicit way to say
> "Not just I am done with one section of my speech, but it is your
> turn to speak and I am going to listen", that would be wonderful.

I think we already have that now in v2 because of the "0001" delim
packet. All of the flushes are (I think) really "this is the end of my
speech", and any inner "my list is ending, but I have more to say"
delimiters are "0001".

-Peff