From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47960) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e06LE-0003iU-7Q for qemu-devel@nongnu.org; Thu, 05 Oct 2017 09:37:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e06LB-00076R-3Z for qemu-devel@nongnu.org; Thu, 05 Oct 2017 09:37:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10079) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e06LA-00076B-R0 for qemu-devel@nongnu.org; Thu, 05 Oct 2017 09:37:29 -0400 References: From: Eric Blake Message-ID: <3ba450aa-a4ff-0601-5912-896717e3bf65@redhat.com> Date: Thu, 5 Oct 2017 08:37:25 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0Bw9o3obd6HqxQPwDXo1mHiSO8K0gdNqX" Subject: Re: [Qemu-devel] nbd structured reply List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Sementsov-Ogievskiy , Wouter Verhelst , Alex Bligh Cc: qemu-devel , "nbd-general@lists.sourceforge.net" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0Bw9o3obd6HqxQPwDXo1mHiSO8K0gdNqX From: Eric Blake To: Vladimir Sementsov-Ogievskiy , Wouter Verhelst , Alex Bligh Cc: qemu-devel , "nbd-general@lists.sourceforge.net" Message-ID: <3ba450aa-a4ff-0601-5912-896717e3bf65@redhat.com> Subject: Re: nbd structured reply References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/05/2017 06:30 AM, Vladimir Sementsov-Ogievskiy wrote: > 21.09.2017 15:18, Vladimir Sementsov-Ogievskiy wrote: >> Hi all! >> >> I'm about this: >> >> "A server SHOULD try to minimize the number of chunks sent in a reply,= >> but MUST NOT mark a chunk as final if there is still a possibility of >> detecting an error before transmission of that chunk completes" >> >> What do we mean by "possibility"? Formally, such possibility exists >> always, so, we'll never mark a chunk as final. >> >=20 > One more question: >=20 > for |NBD_REPLY_TYPE_ERROR and ||NBD_REPLY_TYPE_ERROR_OFFSET, why do we > need message_length field? why not to calc it as chunk.lenght - 4 for > ||NBD_REPLY_TYPE_ERROR and chunk.lenght - 12 for > ||NBD_REPLY_TYPE_ERROR_OFFSET? For consistency. If _all_ NBD_REPLY_TYPE_ERROR* message have a message_length field, then it is easier to write a generic handler that knows how to deal with an unknown error, no matter what command the error is sent in response to. Ideally, a server should never send an error message that the client is not expecting, but having a robust protocol that lets clients deal with bad servers is worth the redundancy caused by being consistent, and we are more likely to add additional error modes to existing commands than we are to add more success modes. >=20 > For example, with NBD_REPLY_TYPE_OFFSET_DATA variable data length is > calculated, not specified separately. That's because non-error types don't have the same consistency concerns; if we want to introduce a new success response, we'll probably introduce it via a new command, rather than as a reply to an existing command. Furthermore, while error replies are likely to have a free-form text error description, success replies tend to not need it. The layout of the error types is designed to make it easy to grab the free-form error message from a known location for display to the user, even if the client has no idea what the rest of the error means, as that may be a useful debugging aid. >=20 > What is the reason for server to send NBD_REPLY_TYPE_ERROR with > message_lenght < chunk.lenght - 4? In all likelihood, all well-written servers will never send garbage bytes (possible only when setting chunk.length larger than message_length + sizeof(documented fields)). But we wrote the spec to be conservative, in case we want to add a later defined field that earlier clients will still gracefully ignore, rather than strict (allowing inequality, instead of requiring exact lengths, lets a client skip over what it considers garbage bytes rather than dropping the connection because a too-new server tried to send useful information in those bytes). --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org --0Bw9o3obd6HqxQPwDXo1mHiSO8K0gdNqX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEEccLMIrHEYCkn0vOqp6FrSiUnQ2oFAlnWNZUACgkQp6FrSiUn Q2rWKQgAgz3S/qmhRGEzKbmN7WlGX4ircjy2pPYoZ1KjW4AtB6a2tya0HedQpr+Z VbkbzMEFi0uYbA2rAh42EF/PVEfoopLhTTp+uAC7pW0rU44yp+h+vBSiBI3r9Hae l/3dBDA1RGKJx7FzF9wwUgRQTWuXVZL+HF3U3p4FXCihyTegU9lcv/a1RGvOZ96t l2ORMuJc5I7dYk16t2n2jDlGDGIlsnVKc6Zy2kYAAA88KHjUdpml2LNyj/ITwdlZ bp5DVfkEC2auZyQXDzsDn7XAXt25tsm0pzd9TImCPYyGMBcJFk5GmWwKanpmhGIU IExWoAFNzQVBGiISBUziQpcvnLFIyg== =1XJL -----END PGP SIGNATURE----- --0Bw9o3obd6HqxQPwDXo1mHiSO8K0gdNqX--