[PATCH] structured-reply: Tweak some protocol requirements
Several tweaks noticed while implementing structured reply for qemu:
- Document what a server may do if the client tries to negotiate
structured replies more than once.
- Reformat the paragraph on NBD_CMD_FLAG_DF.
- Mention what a client should do if a server sends an unexpected
structured reply
Signed-off-by: Eric Blake <eblake@redhat.com>
---
Intended for the extension-structured-reply branch, after first merging
master into that branch. Preview available at:
git://repo.or.cz/nbd/ericb.git extension-structured-reply
http://repo.or.cz/nbd/ericb.git/shortlog/refs/heads/extension-structured-reply
doc/proto.md | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/doc/proto.md b/doc/proto.md
index 5c83cb1..4604a1e 100644
--- a/doc/proto.md
+++ b/doc/proto.md
@@ -1093,6 +1093,8 @@ of the newstyle negotiation.
server MUST use structured replies to the `NBD_CMD_READ`
transmission request. Other extensions that require structured
replies may now be negotiated.
+ - `NBD_REP_ERR_INVALID`: Structured replies have already been
+ previously negotiated.
- For backwards compatibility, clients SHOULD be prepared to also
handle `NBD_REP_ERR_UNSUP`; in this case, no structured replies
will be sent.
@@ -1303,11 +1305,12 @@ valid may depend on negotiation during the handshake phase.
if `NBD_FLAG_SEND_TRIM` was not set in the transmission flags field.
The server MUST support the use of this flag if it advertises
`NBD_FLAG_SEND_WRITE_ZEROES`.
-- bit 2, `NBD_CMD_FLAG_DF`; the "don't fragment" flag, valid during `NBD_CMD_READ`.
- SHOULD be set to 1 if the client requires the server to send at most one
- content chunk in reply. MUST NOT be set unless the transmission
- flags include `NBD_FLAG_SEND_DF`. Use of this flag MAY trigger an
- `EOVERFLOW` error chunk, if the request length is too large.
+- bit 2, `NBD_CMD_FLAG_DF`; the "don't fragment" flag, valid during
+ `NBD_CMD_READ`. SHOULD be set to 1 if the client requires the
+ server to send at most one content chunk in reply. MUST NOT be set
+ unless the transmission flags include `NBD_FLAG_SEND_DF`. Use of
+ this flag MAY trigger an `EOVERFLOW` error chunk, if the request
+ length is too large.
##### Structured reply flags
@@ -1332,7 +1335,9 @@ unrecognized flags.
These values are used in the "type" field of a structured reply.
Some chunk types can additionally be categorized by role, such as
*error chunks* or *content chunks*. Each type determines how to
-interpret the "length" bytes of payload.
+interpret the "length" bytes of payload. If the client receives
+an unknown or unexpected type, other than an *error chunk*, it
+MUST initiate a hard disconnect.
- `NBD_REPLY_TYPE_NONE` (0)
--
2.13.6
Reply to: