Re: [Nbd] [PATCHv8] Improve documentation for TLS
- To: Wouter Verhelst <w@...112...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>, "Daniel P. Berrange" <berrange@...696...>, "qemu-devel@...530..." <qemu-devel@...530...>
- Subject: Re: [Nbd] [PATCHv8] Improve documentation for TLS
- From: Alex Bligh <alex@...872...>
- Date: Tue, 12 Apr 2016 08:47:49 +0100
- Message-id: <0D0FC6E7-F6DA-4B70-A2DD-66ADCD038CA2@...872...>
- In-reply-to: <20160412060155.GF4281@...3...>
- References: <1460292452-1348-1-git-send-email-alex@...872...> <20160411061013.GE28660@...3...> <4942E119-AFFA-42B4-A6DF-2BD6F729D84D@...872...> <570C059E.6090000@...696...> <ECBAC2D7-160B-4E86-A469-00594CB45910@...872...> <20160412060155.GF4281@...3...>
On 12 Apr 2016, at 07:01, Wouter Verhelst <w@...112...> wrote:
> hat doesn't mean OPT_ABORT not having a reply is necessarily a good
> idea. Since it's only used by reference nbd-client in just one use case
> at this point, I don't think it's particularly bad to change the
> definition to say that the server SHOULD send a reply (NBD_REP_ACK),
> upon which the server drops the connection.
>
> The client should probably wait for that too, and not close its socket
> until either it gets a zero read (indicating that the server closed it
> already) or it gets an NBD_REP_ACK from the NBD_OPT_ABORT message.
Yeah. That way would be a safe change (as the worst that can
happen is the client thinks the server has rudely dropped
the connection).
--
Alex Bligh
Reply to: