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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
