Re: [Nbd] [PATCH/RFC] Synchronize the option haggling phase
- To: Wouter Verhelst <w@...112...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>
- Subject: Re: [Nbd] [PATCH/RFC] Synchronize the option haggling phase
- From: Alex Bligh <alex@...872...>
- Date: Thu, 21 Apr 2016 11:31:28 +0100
- Message-id: <D2FB00F1-7D06-43F3-9640-8334A086012F@...872...>
- In-reply-to: <20160420154817.GA14164@...3...>
- References: <1460914313-24533-1-git-send-email-alex@...872...> <57153A59.80905@...696...> <20160420154817.GA14164@...3...>
On 20 Apr 2016, at 16:48, Wouter Verhelst <w@...112...> wrote:
> On Mon, Apr 18, 2016 at 01:49:45PM -0600, Eric Blake wrote:
>> plus simplifications to NBD_OPT_GO:
>>
>> diff --git i/doc/proto.md w/doc/proto.md
>> index 8ef339c..c85e0aa 100644
>> --- i/doc/proto.md
>> +++ w/doc/proto.md
>> @@ -949,11 +949,7 @@ of the newstyle negotiation.
>> with `NBD_REP_ACK`), the client and the server both immediately
>> enter the transmission phase. The server MUST NOT send any zero
>> padding bytes after the `NBD_REP_ACK` data, whether or not the
>> - client negotiated the `NBD_FLAG_C_NO_ZEROES` flag. The server MUST
>> - NOT send the final `NBD_REP_ACK` reply until all other pending
>> - option replies have been sent by the server, and a client MUST NOT
>> - send any further option requests after `NBD_OPT_GO` unless it
>> - first receives an error reply.
>
> These last two lines still apply; a client sending another option after
> having sent NBD_OPT_GO is stupid.
I'm puzzled as to where this bit of patch came from, as it wasn't the one mentioned
in the thread in the header.
--
Alex Bligh
Reply to: