[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] [PATCH v3 1/2] doc: Use dedicated reply types for NBD_OPT_INFO/GO



On 04/14/2016 01:25 AM, Wouter Verhelst wrote:
> Hi Eric,
> 
> On Wed, Apr 13, 2016 at 06:37:29PM -0600, Eric Blake wrote:
>> Since NBD_OPT_INFO and NBD_OPT_GO are experimental, we still have
>> a chance to fix them up before promoting them to stable.
>>
>> Attempting to reuse NBD_OPT_SERVER as the reply to NBD_OPT_INFO and
>> NBD_OPT_GO has a few problems: clients must be prepared to parse
>> two different styles of the reply, based on which option request
>> the reply is answering.  Extending the information to provide even
>> more details, like block sizing, is awkward (the only way to do it
>> within a single reply is to have multiple length fields that must
>> all be consistent; and pre-computing the overall header length may
>> be difficult).  And requiring the server to parrot back the export
>> name is wasteful if the client's name is already in canonical
>> form.
> 
> Right.
> 
>> Solve this by instead making the valid response be a series of reply
>> messages (similar to how NBD_OPT_LIST has a series).  The series
>> is always ended by the new NBD_REP_EXPORT, which is basically a
> 
> If we're going to make it a series of messages, I would prefer that the
> final message be an NBD_REP_ACK. That way, wire sniffers can always spot
> the end of a multi-message reply by way of the ACK at the end, even if
> they don't understand the actual multi-message reply.

Doable, but then we lose the nice property that the tail 10 bytes of
reply to NBD_OPT_GO match the tail 10 bytes of NBD_OPT_EXPORT_NAME. But
that property isn't a show-stopper, so I can go ahead and make that
change (basically, just add NBD_REP_INFO and not NBD_REP_EXPORT; declare
that NBD_INFO_EXPORT is a mandatory reply, and that other infos are
optional).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: