Goswin, Wouter, --On 30 May 2011 13:45:27 +0200 Goswin von Brederlow <[email protected]> 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 ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
