NBD_CMD_DISC does not have a reply. With TLS negotiated (which changes timing, nothing else) what I'm frequently seeing is that the client sends NBD_CMD_DISC then immediately closes the connection (which per doc/proto.md is permissible). Of course NBD_CMD_DISC never actually gets transmitted by the TLS layer, or even it it does it never gets as far as being decoded before the underlying TCP session closes hard.
>From a server's point of view it is thus impossible to reliably distinguish >between an intended clean close, and a dirty close, which is an unfortunate >state of affairs. This would be remedied by introducing a reply for NBD_CMD_DISC (signalled somehow - yet another flag I guess), the idea being that the client SHOULD wait for a reply before closing the connection. Now if the server closes the connection hard whilst the reply is still in the TLS buffer (either server side or client side) this won't be a disaster as from the server's point of view the close was clean, and the client can consider a hard close after sending NBD_CMD_DISC as a clean close anyway. WDYT? -- Alex Bligh ------------------------------------------------------------------------------ _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
