[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] Processing client's option list



Wouter Verhelst <w@...112...> writes:

> On Sun, May 29, 2011 at 10:06:20AM +0100, Alex Bligh wrote:
>> Wouter,
>> 
>> --On 16 May 2011 23:01:51 +0100 Alex Bligh <alex@...872...> wrote:
>> 
>> > Hmm... Another problem. How does the server know when it has
>> > reached the end of the client's option list? I'd suggest
>> > the client writes 4 octets of zero (in place of another
>> > option identifier), but that's possibly not API
>> > compatible.
>> 
>> Can I remind you about this one? I'm puzzled about how this is
>> meant to work.
>
> I overlooked that when I defined the new negotiation. Worse, it's not
> possible to add new messages without breaking the protocol, since the
> server doesn't currently ignore any options it doesn't know about.
>
> So, here's a suggestion:
> - The server sets a flag "I have a fixed new-style negotiation
>   implementation"
> - The client replies with a similar flag.
> - Only if both client and server have set that bit can extra options be
>   used. In that case, the server must continue reading data until it
>   reads a packet NBD_OPT_END, with zero length. It must echo that back
>   to the client when it has nothing more to say.
> - The server must not send any data to the client beyond what is
>   required for any explicit requests by the client and the NBD_OPT_END
>   packet.
>
> This way, both the client and the server will know when negotiation is
> finished, even if one or the other does not implement an option that is
> requested by the other end.
>
> Thoughts?

Currently NBD_OPT_EXPORT_NAME is the only possible option and it is also
required. How about declaring that NBD_OPT_EXPORT_NAME must be the last
option being send and ends the negotiation?

That would be compatible with existing behaviour and allow to add new
options.

Only problem with that design would be if in the future there will be
options that require the export name to be known before the server can
decide how to reply.

MfG
        Goswin



Reply to: