From patchwork Tue Mar 29 23:00:59 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Blake X-Patchwork-Id: 8691551 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 2D1CF9F30C for ; Tue, 29 Mar 2016 23:03:35 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 832AC2034C for ; Tue, 29 Mar 2016 23:03:34 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C51A62034B for ; Tue, 29 Mar 2016 23:03:33 +0000 (UTC) Received: from localhost ([::1]:50416 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1al2fd-0006rP-AO for patchwork-qemu-devel@patchwork.kernel.org; Tue, 29 Mar 2016 19:03:33 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48443) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1al2fT-0006mP-4j for qemu-devel@nongnu.org; Tue, 29 Mar 2016 19:03:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1al2fO-0006Pr-SA for qemu-devel@nongnu.org; Tue, 29 Mar 2016 19:03:21 -0400 Received: from resqmta-po-01v.sys.comcast.net ([96.114.154.160]:53279) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1al2fO-0006Pa-NP for qemu-devel@nongnu.org; Tue, 29 Mar 2016 19:03:18 -0400 Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by comcast with SMTP id l2dPaVfioTVC4l2dPavuxK; Tue, 29 Mar 2016 23:01:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1459292475; bh=6l0FzhklaKoAg2GzYSvIvm270oSLXmTBU017e31vHs0=; h=Received:Received:From:To:Subject:Date:Message-Id; b=FssuTtnULMl/zjZ96FFItZOA5mRcWVHbJnND8fZw9+65pvp+AJf5Tm/G9yoNQc8Ek UUifGeKK6XRgadYHHH4ybMWOA6zUn+kbXpy0/Xvi3euNiDmzMLwirby1912rrvwCas m6y+QdwUcsIaCvekoZkiuPjic996uBz53UtGupspc4ErwJg2Rp+IoWEVv6DGXg3eNa d5g2ogbKpeoAKGCYC0/cxW8tRuSjNEyG78y0j58SGEbIBxcV6Gu9QH/p6iziYL2IaF HXRzVs4U+o73yzgRrhKWAuosFd3Z3jCwbCUAPma5KIu+wKaLRwX0xmnX0Ap4j+1laj EEqc2SY4+OcBw== Received: from red.redhat.com ([24.10.254.122]) by resomta-po-04v.sys.comcast.net with comcast id bz111s0012fD5rL01z1EHC; Tue, 29 Mar 2016 23:01:15 +0000 From: Eric Blake To: nbd-general@lists.sourceforge.net Date: Tue, 29 Mar 2016 17:00:59 -0600 Message-Id: <1459292460-6875-3-git-send-email-eblake@redhat.com> X-Mailer: git-send-email 2.5.5 In-Reply-To: <1459292460-6875-1-git-send-email-eblake@redhat.com> References: <1459173555-4890-1-git-send-email-eblake@redhat.com> <1459292460-6875-1-git-send-email-eblake@redhat.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 96.114.154.160 Cc: w@uter.be, qemu-devel@nongnu.org, alex@alex.org.uk Subject: [Qemu-devel] [PATCH v2 2/3] doc: Mention proper use of handle X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Although the proper use of the handle field during transmission phase was implied, it never hurts to make it more explicit that clients should use distinct handles for multiple in-flight requests. Likewise, the server must repeat the handle unchanged, in order for the client to track when the server is sending replies out of order. Make it clear that the client does not have to follow any particular order of handles, and can reuse values. Signed-off-by: Eric Blake --- doc/proto.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/doc/proto.md b/doc/proto.md index 3d49162..3f9ee23 100644 --- a/doc/proto.md +++ b/doc/proto.md @@ -203,7 +203,13 @@ 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 use a +handle that is distinct from all other currently pending transactions, +but MAY reuse handles that are no longer in flight; handles need not +be consecutive. In each reply, the server MUST use the same value for +handle as was sent by the client in the corresponding request. In +this way, the client can correlate which request is receiving a +response. ## Values