On 10/18/2017 11:19 AM, Wouter Verhelst wrote: > On Mon, Oct 16, 2017 at 10:25:24AM -0500, Eric Blake wrote: >> 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> >> --- >> +++ 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. > > I'm not sure that's really a problem. > > If a client wants to do structured replies, the server should ensure > that the bit "structured replies are okay" is set. If it's already set, > it's already set and we're fine. > > The TLS situation is somewhat different; if a client wants to do TLS, > the server should fire up the TLS library and initiate the encryption. > Once that's already done, you can't do it again. There is no useful > response to that. > > Having said that though, I don't feel too strongly about it. Any way to word it that they server MAY fail with ERR_INVALID on duplicate response (but not MUST), and therefore the client SHOULD NOT send duplicates (but not MUST NOT)? Another consideration - I know at least nbdkit enforces a cap on the maximum number of NBD_OPT that a client may send before it must move into transmission phase, on the grounds that otherwise, a client can cause a denial of service by tying up server state with an infinite stream of useless NBD_OPT requests preventing the server from handling other well-behaved clients. Should that be documented in the standard somehow (that a server MAY disconnect if NBD_OPT_GO is not received in a timely manner, but conversely setting appropriate minimum bounds that it MUST accept so that clients need not worry about getting enough handshake done)? Now that we have NBD_OPT_LIST and NBD_OPT_INFO, it's harder to pin down a finite limit (if you return 100 exports in your list, and the client then asks for info on each of those 100 exports, that's NOT a client being belligerent - nbdkit's limit of 16 is based more on the fact that it's reply to NBD_OPT_LIST is exactly one item). Although by the time we start documenting this, it's no longer specific to NBD_OPT_STRUCTURED_REPLY, and would belong on the mainline. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature