On 04/11/2016 01:27 AM, Alex Bligh wrote: >>> +There is no requirement for the client or server to complete a negotiation >>> +if it does not wish to do so. If the client does not find an export it >>> +is looking for (for instance) it may simply close the TCP connection. >>> +Under certain circumstances either the client or the server may be required >>> +by this document to close the TCP connection. In each case, this is >>> +referred to as 'terminate the session'. >>> + >>> ### Transmission >> >> NAK. If we have disconnect messages (NBD_OPT_ABORT and NBD_CMD_DISC), it >> makes sense to say that clients should use them. Protocol violations by >> peers are a different matter; but in the general case you should drop a >> connection properly, i.e., by using the relevant "close the connection" >> command. >> >> (I realize I didn't comment on this earlier, but I changed my mind >> during the discussion about DISC). > > This section only relates to the negotiation phase, so really this is > about use (or not) or NBD_OPT_ABORT, not NBD_OPT_DISC. > > Your statement is a bit surprising though as far as NBD_OPT_ABORT > is concerned. > > Firstly, there is no way to the *server* to send NBD_OPT_ABORT. > That's what this paragraph was primarily aimed at. > > Secondly proto.md has: > >> The phase continues until either side closes the connection. > > That implies that either the client or the server can initiate the > close. > > I thought on this basis its use was entirely optional. > > NBD_OPT_ABORT says: > >> - `NBD_OPT_ABORT` (2) >> >> The client desires to abort the negotiation and close the >> connection. >> > > I *presume* it has a reply (all the others do). Should a client > wait for the undocumented reply before closing its end of > the connection or not? I must admit the semantics are sufficiently > opaque though I support it server side (with a reply) I would > never sent it client side. Current qemu NBD server implementation does NOT send a reply to NBD_OPT_ABORT, but immediately closes the connection. I don't know if that is a bug in qemu (especially given the discussion on NBD_CMD_DISC), but it is an independent issue from TLS documentation, so may be better discussed on that thread. Likewise, current qemu NBD client implementation does NOT send NBD_OPT_ABORT at all, so it's hard to say whether waiting around for a reply is worthwhile. > > Obviously NBD_OPT_ABORT and aborting the connection needs > more clearing up, but I'm loathe to do it in the TLS patch. > > In order not to make things worse, how about: > >> There is no requirement for the client or server to complete a >> negotiation if it does not wish to do so. Either end may simply >> close the TCP connection (though see below re prior use Not sure if the use of "re" is ideal (are you abbreviating for "regarding")? >> of NBD_OPT_ABORT). Under certain circumstances either >> the client or the server may be required by this document to close >> the TCP connection. In each case, this is referred to as 'terminate >> the session'. >> >> If the client wishes to terminate the session in the negotiation >> phase, and is not doing so because it is required to do so >> by this document, it SHOULD send NBD_OPT_ABORT first if the protocol >> permits. There are instances where this is impossible, such as after >> an NBD_OPT_EXPORTNAME has been issued, or on an unsuccessful >> negotiation of TLS. For instance, if the client does not find an >> export it is looking for, it may simply send an NBD_OPT_ABORT >> and close the TCP connection. Otherwise, this seems reasonable, other than the fact that qemu needs patches to actually start sending NBD_OPT_ABORT where possible. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature