Currently the protocol permits options to be sent even when there are outstanding replies, and for the server to process those options out of order. This causes a number of issues.
If option replies remain outstanding when NBD_OPT_STARTTLS is issued then those replies may arrive unencrypted when NBD_OPT_STARTTLS is processed. Similarly options sent after NBD_OPT_STARTTLS is issued (but not replied to) may be sent unencrypted but are expected to be encrypted. This is difficult to track server side. This needs fixing in any case, and it's better to fix it for all options. Few (if any) known clients issue options without waiting for replies, and few (if any) servers do anything other than process replies. So the ability to send options without waiting for replies gives few benefits. It also complicates the specification, and (as it is so little tested) is a ripe field for subtle bugs where the protocol authors assume that a reply to a given option has been received before the client sends another option. Without this serialisation, it is not possible to effectively enforce things like "The client MUST NOT send NBD_OPT_X if the server has previously replied NBD_REP_Y" because the client can send NBD_OPT_X before receiving the reply. Signed-off-by: Alex Bligh <[email protected]> --- doc/proto.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) This one is my preferred fix. diff --git a/doc/proto.md b/doc/proto.md index 24ab813..07f18b0 100644 --- a/doc/proto.md +++ b/doc/proto.md @@ -194,12 +194,10 @@ S: 32 bits, length of the reply. This MAY be zero for some replies, in S: any data as required by the reply (e.g., an export name in the case of `NBD_REP_SERVER`) -As there is no unique number for client requests, clients who want to -differentiate between answers to two instances of the same option during -any negotiation must make sure they've seen the answer to an outstanding -request before sending the next one of the same type. The server MAY -send replies in the order that the requests were received, but is not -required to. +The client MUST NOT send any option until it has received a final +reply to any option it has sent (note that some options e.g. +`NBD_OPT_LIST` have multiple replies, and the final reply is +the last of those). #### Termination of the session during option haggling -- 1.9.1 ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
