[Nbd] [PATCH/RFC] Synchronize the option haggling phase
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 <alex@...872...>
---
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
Reply to: