Re: [Nbd] Processing client's option list

[Wouter Verhelst <w@...112...>]

On Sun, May 29, 2011 at 01:33:23PM +0200, Goswin von Brederlow wrote:
> 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?

Yes, that sounds like a better way; and if the client sends more than
just NBD_OPT_EXPORT_NAME, the server must then reply with some
confirmation that it's parsed all options and thinks negotiation is
finished. It must not do so if only NBD_OPT_EXPORT_NAME has been
specified.

> 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.

If that ever happens, we can have the server set a flag to communicate
to the client that the server knows about these options, to which the
client can then reply with a message that it wants to use one (or more)
of them. It's a bit ugly, but not as bad as what I suggested above.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a