Wouter,

On 11 Apr 2016, at 07:10, Wouter Verhelst <[email protected]> wrote:

> Mostly there. Final note:
> 
> On Sun, Apr 10, 2016 at 01:47:32PM +0100, Alex Bligh wrote:
>> diff --git a/doc/proto.md b/doc/proto.md
>> index f117394..5005552 100644
>> --- a/doc/proto.md
>> +++ b/doc/proto.md
>> @@ -195,6 +195,13 @@ request before sending the next one of the same type. 
>> The server MAY
>> send replies in the order that the requests were received, but is not
>> required to.
>> 
>> +There is no requirement for the client or server to complete a negotiation
>> +if it does not wish to do so. If the client does not find an export it
>> +is looking for (for instance) it may simply close the TCP connection.
>> +Under certain circumstances either the client or the server may be required
>> +by this document to close the TCP connection. In each case, this is
>> +referred to as 'terminate the session'.
>> +
>> ### Transmission
> 
> NAK. If we have disconnect messages (NBD_OPT_ABORT and NBD_CMD_DISC), it
> makes sense to say that clients should use them. Protocol violations by
> peers are a different matter; but in the general case you should drop a
> connection properly, i.e., by using the relevant "close the connection"
> command.
> 
> (I realize I didn't comment on this earlier, but I changed my mind
> during the discussion about DISC).

This section only relates to the negotiation phase, so really this is
about use (or not) or NBD_OPT_ABORT, not NBD_OPT_DISC.

Your statement is a bit surprising though as far as NBD_OPT_ABORT
is concerned. 

Firstly, there is no way to the *server* to send NBD_OPT_ABORT.
That's what this paragraph was primarily aimed at.

Secondly proto.md has:

> The phase continues until either side closes the connection.

That implies that either the client or the server can initiate the
close.

I thought on this basis its use was entirely optional.

NBD_OPT_ABORT says:

> - `NBD_OPT_ABORT` (2)
> 
>     The client desires to abort the negotiation and close the
>     connection.
> 

I *presume* it has a reply (all the others do). Should a client
wait for the undocumented reply before closing its end of
the connection or not? I must admit the semantics are sufficiently
opaque though I support it server side (with a reply) I would
never sent it client side.

Note also that in some circumstances where I document 'terminate
the session' it's not possible for the client to send an NBD_OPT_ABORT.
The two obvious ones are:

* After NBD_OPT_EXPORTNAME has been issued - if for instance
  the client does not like the flags.

* After NBD_OPT_STARTTLS has been issued and the NBD_REP_ACK
  has been sent, but the TLS handshake itself fails client
  side (for instance the server cert does not work).

Obviously NBD_OPT_ABORT and aborting the connection needs
more clearing up, but I'm loathe to do it in the TLS patch.

In order not to make things worse, how about:

> There is no requirement for the client or server to complete a
> negotiation if it does not wish to do so. Either end may simply
> close the TCP connection (though see below re prior use
> of NBD_OPT_ABORT). Under certain circumstances either
> the client or the server may be required by this document to close
> the TCP connection. In each case, this is referred to as 'terminate
> the session'.
> 
> If the client wishes to terminate the session in the negotiation
> phase, and is not doing so because it is required to do so
> by this document, it SHOULD send NBD_OPT_ABORT first if the protocol
> permits. There are instances where this is impossible, such as after
> an NBD_OPT_EXPORTNAME has been issued, or on an unsuccessful
> negotiation of TLS.  For instance, if the client does not find an
> export it is looking for, it may simply send an NBD_OPT_ABORT
> and close the TCP connection.


-- 
Alex Bligh





------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532
_______________________________________________
Nbd-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nbd-general

Reply via email to