Re: [Nbd] Thoughts about the handshake protocol

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

On Wed, Jun 01, 2011 at 02:35:00PM +0200, Goswin von Brederlow wrote:
> Wouter Verhelst <w@...112...> writes:
> 
> > On Tue, May 31, 2011 at 01:38:44PM +0200, Goswin von Brederlow wrote:
> >> Wouter Verhelst <w@...112...> 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.

Right, but that's why there might be that second option.

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

Ah, hrm. Yeah, that might be confusing, indeed; didn't think of that.

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

the section header name.

[generic]
[export1]
	exportname = /srv/nbd/foo

means you can access it with

nbd-client -N export1

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

pi zz a