Re: [Nbd] Thoughts about the handshake protocol

[Goswin v. B. <gos...@we...>]

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

> On Tue, May 31, 2011 at 01:38:44PM +0200, Goswin von Brederlow wrote:
>> Wouter Verhelst <w...@ut...> writes:
>> 
>> > On Tue, May 31, 2011 at 10:28:38AM +0200, Goswin von Brederlow wrote:
>> >> C: NBD_OPT_EXPORT_NAME foo
>> >> S: size+flags
>> >> C: NBD_OPT_SYNC
>> >> -- wait --
>> >> C: NBD_OPT_END
>> >> -- wait --
>> >> C - switching to nbd mode
>> >> S: error, NBD_OPT_SYNC not known
>> >> 
>> >> At that point the kernel will be quite confused and kill the connection.
>> >
>> > No, not that way.
>> >
>> > C: NBD_OPT_EXPORT_NAME foo
>> > S: size + flags
>> > C: NBD_OPT_FOO
>> > C: NBD_OPT_END
>> > S: error, NBD_OPT_SYNC not known
>> > S: NBD_OPT_END
>> > C: disconnect or switch to kernel
>> >
>> > [...]
>> 
>> So NBD_OPT_END would allways have a reply. That would work in this case
>> too.
>> 
>> But what if you have conflicting options A | B? The client first tries
>> to set option A. If the server doesn't know that it wants to fall back
>> to B. But it doesn't want option B unless A fails.
>
> Let's say that the server must issue out error messages as soon as
> possible (i.e., it must not wait until the NBD_OPT_END message has been
> received, but must issue them as soon as it finds that there would be an
> error condition). That way, the client has two options:
>
> - select() on the socket with a timeout to see whether the server issues
>   an error about an unknown option; if not, assume the option has been
>   accepted
> - deliberately issue an invalid option. That way, the server would
>   need to issue an error message, and the client can see whether another
>   error message appears before that and doesn't need to wait for an
>   indefinite amount of time.

I don't like having to assume something based on a vague timeout.

>> >> > Mmm. I'd prefer a newline-separated list of export names, that's going
>> >> > to be easier -- and there's no need to support complex export names.
>> >> 
>> >> Works too. What can an export name be? Any UTF-8 string not containing 0
>> >> and \n? Only printable ascii chars? [-_0-9a-zA-Z.:#+]?
>> >
>> > I'd say letters and numbers, and must not start with a number.
>> 
>> The new style calls for them to be the full path,
>
> Wrong. Whatever gave you that idea?

       exportname
              Required; string.

              The name of the file (or block device) that will be
              exported.  This must be a fully-qualified path and
              filename; relative paths are not allowed.

> There is no relation whatsoever between the name of an export and the
> name of the exported file.

So where does the name of the export, which aprently isn't exportname,
come from?

MfG
        Goswin