Wouter,

--On 29 May 2011 11:29:14 +0200 Wouter Verhelst <[email protected]> wrote:

> I overlooked that when I defined the new negotiation. Worse, it's not
> possible to add new messages without breaking the protocol, since the
> server doesn't currently ignore any options it doesn't know about.
>
> So, here's a suggestion:
> - The server sets a flag "I have a fixed new-style negotiation
>   implementation"
> - The client replies with a similar flag.
> - Only if both client and server have set that bit can extra options be
>   used. In that case, the server must continue reading data until it
>   reads a packet NBD_OPT_END, with zero length. It must echo that back
>   to the client when it has nothing more to say.
> - The server must not send any data to the client beyond what is
>   required for any explicit requests by the client and the NBD_OPT_END
>   packet.
>
> This way, both the client and the server will know when negotiation is
> finished, even if one or the other does not implement an option that is
> requested by the other end.

I don't think you mean "packet". I think you just mean "option". They
need not be separate tcp packets. Otherwise yes, I agree.

Alternatively, if we have room, perhaps the server could indicate
what protocol revision it supports, then the client could reply
with a number less than or equal to that, and we could just do
revisions of protocols, rather than trying to support all sorts
of different things orthogonally.

-- 
Alex Bligh

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Nbd-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nbd-general

Reply via email to