Re: [Nbd] [RFC] NBD protocol improvement

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

On Fri, Sep 26, 2008 at 09:31:12AM +0200, Laurent Vivier wrote:
> Le jeudi 18 septembre 2008 à 12:21 +0200, Laurent Vivier a écrit :
> > Le jeudi 18 septembre 2008 à 10:35 +0200, Wouter Verhelst a écrit :
> > > 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:
> > [...]
> > > > > 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 :-)
> > 
> > It's why I used a size set to 0 in the negotiation packet to get the
> > information from the server to the client. Because 0 is not a valid
> > value for a size, the client knows it has to send a name and the server
> > knows it has to wait a name.
> 
> Any comments ?

Sorry; I thought I'd replied, but apparently that didn't happen.

If you're going to do that, the server will not be able to negotiate a
connection with a client that doesn't understand this option if you
enable it. If that's going to happen anyway, I think it's probably
better to change things in such a way that we /can/ change the handshake
in the future without having to lose compatibility.  Overloading the
size parameter in such a way that it signals this particular condition
doesn't do that, so I'd prefer that at least the client gets a step
where it gets to send a few 'reserved' bits of its own to the server.

Whether you do that by changing the protocol incompatibly or not is up
to you; I'd prefer you do not change it incompatibly if at all possible,
but if that makes the code too hairy or unmaintainable, forget it.

-- 
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22