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