Re: [Nbd] Thoughts about the handshake protocol

[Alex Bligh <alex@...872...>]

Goswin, Wouter,

--On 30 May 2011 13:45:27 +0200 Goswin von Brederlow <goswin-v-b@...186...> 
wrote:

> revently it was mentioned that the new-style handshake has some problems
> and needs some fixing up for the future. So I wanted to collect some
> thoughts about this to maybe spark a redesign. Turned out to describe
> pretty much the complete handshake. Let me know what you think:

Having just written a state-machine to do a non-blocking handshake
for an nbd compatible server, I would agree whole heartedly that
the handshake protocol could "do with some rethinking".

Currently my view is that we should probably just use a different
magic number and start again from scratch. Or signal a
"true option exchange" by using the server indicating
it supports it and the client agreeing in first 2 words.
My thoughts are below.

> ----------------------------------------------------------------------
> Currently the handshake starts with:
>
> S: "NBDMAGIC" (as in the old style handshake)
> S: 0x49484156454F5054 (note different magic number)
> S: 16 bits of zero (reserved for future use)
> C: 32 bits of zero (reserved for future use)
>
> So the server identifies itself as NBD server. The client though does
> not identify itself but just starts sending payload.

Moreover, there is no real versioning for client requests.

> Next the option haggling is a good idea. But it lacks a way for the
> server to say when it doesn't understand an option and for the client to
> say there are no more option coming.

What I was thinking is something like the following (this is a
brain dump you might want to combine with your idea rather than
an alternative):

OptionReceiver says: "I understand these options" (+ list)
OptionSender sends the relevant option, one by one.
OptionReceiver OK's / errors each one as they come through.
OptionSender's last option is a "no more options" pad (acknowledged
as usual).
All options should have a length.

I've written OptionSender and OptionReceiver as I think option
negotiation should be 2-way (i.e. the server should be able to
send options to the client too). I would allow the client and
server to send blocks of options to eachother (alternately)
until they send an empty set of options (meaning done).

The first option the client sends (not the last) should be the
export name, because that's what you need to return things like
size.

*Everything* else should be an option - client flags, server flags,
size of disk, etc. etc. - i.e. there should be nothing but
options negotiated this way

I agree there's all sorts of interesting stuff we could do with
options.

Obviously, we need it to remain back compatible, but my thought
is a "version 3" protocol may be the way to go, as there are
lots of weirdnesses in the "modern protocol", e.g. 124 bytes
of zeroes, options sent unidirectionally etc. etc.

The thing I'd add though is that this work is probably only
going to get done if there is a user for these new options.

--
Alex Bligh