On 10/18/2017 02:52 PM, Wouter Verhelst wrote: >>> >>> 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)? > > Probably best to do something along those lines, yes, although we should > perhaps say it in more generic terms that encompass any message the > client shouldn't have to send more than once. > > something like... > > "Some messages the client sends instruct the server to change some of > its internal state. The client SHOULD NOT send such messages more than > once. If it does, the server MAY fail the message with > NBD_REP_ERR_INVALID." > > ? > > not sure where exactly to put it though. Giving it a shot as a patch mail... > >> 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)? > > I thought we had wording to that effect already? > > <checks> > > the section "Termination of the session during option haggling" already > has a bit saying "except that if a server believes a client's behaviour > constitutes a denial of service, it MAY initiate a hard disconnect", > which if I recall correctly was added precisely to document the nbdkit > behaviour in this regard. > > I suppose we can reword that if you think we can do it better, but let's > not re-document the same behaviour three times? ;-) Okay, for this issue, I'm satisfied by the existing wording; thanks for reminding me of it! -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature