Actually I was wrong, there *is* one substantive change over v1, which is this:
+ /* The client is buggy. The last option must be NBD_OPT_GO or + * NBD_OPT_EXPORT_NAME. + */ + else { + nbdkit_error ("client options list didn't finish with NBD_OPT_GO " + "or NBD_OPT_EXPORT_NAME"); + return -1; + } + return 0;
Current behaviour in nbdkit is that if the last requested option is a recognized option, but is not NBD_OPT_EXPORT_NAME then nbdkit will send the handshake_finish struct and continue to transport mode. However I don't think nbdkit is currently behaving correctly. In any case the proposed behaviour (above) is that in this case we will close the connection abruptly and record an error in the log. (There's no way to return an error back to the client when we get into this situation.) I am not certain if this is correct or not, but I believe it is: the NBD protocol says the only way to exit option mode and enter transmission mode is: "Transmission mode can be entered (by the client sending NBD_OPT_EXPORT_NAME or by the server responding to an NBD_OPT_GO with NBD_REP_ACK)." (The other two ways mentioned in that section are about terminating the connection completely). This also implies that the number of options must never be zero, which the spec does say in passing: "At this point, we move on to option haggling, during which point the client can send one or (in fixed newstyle) more options to the ~~~ server." The current nbdkit code assumes this, so we're OK there. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top