On Wed, Sep 15, 2021 at 12:11:35PM +0300, Vladimir Sementsov-Ogievskiy wrote: > > > > There are two methods of terminating the transmission phase: > > > > ... > > > > "The client or the server drops the TCP session (in which case it > > > > SHOULD shut down the TLS session first). This is referred to as > > > > 'initiating a hard disconnect'." > > > > > > Right. Here the method is defined, no word that client can do it at any > > > time.
Note that right now, most TLS clients are NOT gracefully shutting down the TLS session, on either hard or soft disconnect. And this is even observable in non-deterministic behavior of what message the server reports when it diagnoses that a TLS client has gone away. As argued elsewhere, a hard disconnect does not necessarily lose data, but it does add non-determinism into the equation, which makes regression testing a bit harder. > > > > I don't read this as a definition. > > If so, next paragraphs that specify client behavior doesn't make sense. > > > > > But we should probably clarify the spec to note that dropping the > > connection is fine, because it is - no one has made any argument so > > far that there's an actual reason to waste time on NBD_CMD_DISC. > > > > I agree that it's safe enough.. > > Hmm. If we update the spec to clarify that sending DISC is not necessary, is > there any reason to send it at all? We can stop sending it in Qemu as well. No, I'd still prefer that qemu send NBD_CMD_DISC where possible. Although existing servers tolerate hard disconnects, the way I read the NBD spec is that clients SHOULD prefer soft disconnect, in case it deals with a server where the difference matters. When implementing 'qemu-nbd --list', I remember having to rejigger code to add in a graceful NBD_OPT_ABORT into more places, for the same reason as sending NBD_CMD_DISC at the end of transmission phase reduces the chance for non-determinism on how the server may react. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
