Re: [Nbd] [RFC] NBD protocol improvement
- To: Laurent Vivier <Laurent.Vivier@...154...>
- Cc: nbd-general@lists.sourceforge.net
- Subject: Re: [Nbd] [RFC] NBD protocol improvement
- From: Wouter Verhelst <w@...112...>
- Date: Thu, 18 Sep 2008 10:35:27 +0200
- Message-id: <20080918083527.GB3319@...172...>
- In-reply-to: <1221576985.4172.26.camel@...156...>
- References: <1221119881.4145.13.camel@...156...> <48C94529.40307@...124...> <1221160674.4124.6.camel@...156...> <20080912060352.GA3733@...172...> <1221576985.4172.26.camel@...156...>
On Tue, Sep 16, 2008 at 04:56:25PM +0200, Laurent Vivier wrote:
> Le vendredi 12 septembre 2008 à 08:03 +0200, Wouter Verhelst a écrit :
> > On Thu, Sep 11, 2008 at 09:17:54PM +0200, Laurent Vivier wrote:
> > > Le jeudi 11 septembre 2008 à 12:19 -0400, Paul Clements a écrit :
> > > > Laurent Vivier wrote:
> > > > > * NBD server side:
> > > > >
> > > > > - put all the disk images in a directory, for instance:
> > > > >
> > > > > # ls /ISO
> > > > > ubuntu-6.06-desktop-amd64.iso
> > > > > ubuntu-7.10-desktop-amd64.iso
> > > > > ubuntu-8.04-desktop-i386.iso
> > > > >
> > > > > - run the NBD server with a new parameter to specify the directory
> > > > > instead of the filename
> > > > >
> > > > > # nbd-server 1024 --read-only --directory /ISO
> >
> > I'm currently considering the command-line interface of NBD to be
> > deprecated; instead, I'd prefer it if you would add a new config file
> > parameter.
>
> OK.
> Is "directory" a good name for this parameter ?
Yeah, I'd think so.
> > Also, it might be interesting to add a 'default' option, so that clients
> > that don't understand the new thing would at least get something.
> >
> > That would require some changes to your proposal below, though:
> >
> > > > > * NBD client side
> > > > >
> > > > > nbd-client isoserver 1024 /dev/nbd0 ubuntu-8.04-desktop-i386.iso
> > > > >
> > > > > * protocol changes:
> > > > >
> > > > > - when used with "--directory", nbd-server sends a disk size of 0 in the
> > > > > negotiate operation.
> >
> > This should then be the size of the default option instead (or 0 if
> > there is no default).
>
> OK
>
> > The 'flags' field in the negotiation should get another flag, signalling
>
> OK
>
> > that there are alternate exports. If the client replies with a flag of
> > its own, signalling that it knows about those, then it should send a
> > filename, as below.
>
> Is the protocol already includes this behavior (client returns known
> flags) ? if yes, where ? I didn't find it. If not, I don't see how to
> add it without breaking all.
Ah, you're right. I thought there was one, but I'm mistaken.
Hmm. The first packet ever sent by an nbd-client after successfully
negotiating a connection is an nbd_request struct; this starts with a
magic number. As such, it should be possible to distinguish between this
magic number and a flags field that gets sent first, provided we make
sure they never look the same (e.g., by having the first bit be ~(the
first bit of the magic number).
That's going to be quite messy, though; you'd need to special-case the
first (and only the first) packet. Hmm. Perhaps if you make the 'flags'
field the same size of an nbd_request; then you could read in the entire
packet, check whether it looks like a request, and then either parse the
flags or fire of the request handler, depending on whether it does.
At some point I should probably change the protocol incompatibly :-)
[...]
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Reply to: