On Sun, May 29, 2011 at 01:33:23PM +0200, Goswin von Brederlow wrote: > Wouter Verhelst <[email protected]> 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 <[email protected]> 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 ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
