Re: [Nbd] [PATCH] doc: Mention proper use of handle
- To: Eric Blake <eblake@...696...>
- Cc: nbd-general@lists.sourceforge.net, qemu-devel@...530...
- Subject: Re: [Nbd] [PATCH] doc: Mention proper use of handle
- From: Wouter Verhelst <w@...112...>
- Date: Tue, 29 Mar 2016 09:11:24 +0200
- Message-id: <20160329071124.GA22386@...3...>
- In-reply-to: <1459173555-4890-1-git-send-email-eblake@...696...>
- References: <1459173555-4890-1-git-send-email-eblake@...696...>
On Mon, Mar 28, 2016 at 07:59:15AM -0600, Eric Blake wrote:
> Although the proper use of the handle field during transmission
> phase was implied, it never hurts to make it more explicit that
> clients should alter the handle on each message, and the server
> repeat the handle unchanged, in order for the client to track
> when the server is sending replies out of order.
>
> Signed-off-by: Eric Blake <eblake@...696...>
> ---
> doc/proto.md | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/doc/proto.md b/doc/proto.md
> index 6d1cb34..d0102e0 100644
> --- a/doc/proto.md
> +++ b/doc/proto.md
> @@ -200,7 +200,11 @@ S: 64 bits, handle
> S: (*length* bytes of data if the request is of type `NBD_CMD_READ`)
>
> Replies need not be sent in the same order as requests (i.e., requests
> -may be handled by the server asynchronously).
> +may be handled by the server asynchronously). Clients SHOULD send a
> +different value of handle for each request, and the server MUST use the
> +same value for handle as was sent by the client for each request that
> +the server is replying to, so that the client may correlate which
> +request is receiving a response.
NAK. This implies that a client should not ever reuse handles, while it
is legal for a client (and in fact the kernel does this) to reuse
handles once the server has ack'd the request.
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
Reply to: