4.1 client reconnect bug

4.1 client reconnect bug

[J. Bruce Fields]

Following up on a pub conversation from a couple weeks ago:

The client apparently assumes that (in the absence of state protection)
sending a SEQUENCE over a new tcp connection to the server automatically
associates the new tcp connection with both the forechannel and
backchannel of the session.

The server currently assumes that the new tcp connection should be
associated only with the forechannel.

RFC 5661 sides with the forechannel-only convention:

	- 2.6.10.6.2: "If the client wants to use additional connections
	  for the backchannel, then it needs to call
	  BIND_CONN_TO_SESSION on each connection it wants to use with
	  the session."

	- 2.10.13.1.2: "If the connection that was lost was the last one
	  associated with the backchannel, and the client wants to
	  retain the backchannel and/or prevent revocation of recallable
	  state, the client needs to reconnect, and if it does, it MUST
	  associate the connection to the session and backchannel via
	  BIND_CONN_TO_SESSION."

	- 18.34.3: "If, when the client ID was created, the client opted
	  for SP4_NONE state protection, the client is not required to
	  use BIND_CONN_TO_SESSION to associate the connection with the
	  session, unless the client wishes to associate the connection
	  with the backchannel."

That means that currently if the client attempts to reconnect (e.g. to
resend a timed-out rpc), it will see SEQ4_STATUS_CB_PATH_DOWN_SESSION
set on future SEQUENCE replies.

--b.

Re: 4.1 client reconnect bug

[Trond Myklebust]

On Mon, 2011-10-17 at 17:04 -0400, J. Bruce Fields wrote: 
> Following up on a pub conversation from a couple weeks ago:
> 
> The client apparently assumes that (in the absence of state protection)
> sending a SEQUENCE over a new tcp connection to the server automatically
> associates the new tcp connection with both the forechannel and
> backchannel of the session.
> 
> The server currently assumes that the new tcp connection should be
> associated only with the forechannel.
> 
> RFC 5661 sides with the forechannel-only convention:
> 
> 	- 2.6.10.6.2: "If the client wants to use additional connections
> 	  for the backchannel, then it needs to call
> 	  BIND_CONN_TO_SESSION on each connection it wants to use with
> 	  the session."
> 
> 	- 2.10.13.1.2: "If the connection that was lost was the last one
> 	  associated with the backchannel, and the client wants to
> 	  retain the backchannel and/or prevent revocation of recallable
> 	  state, the client needs to reconnect, and if it does, it MUST
> 	  associate the connection to the session and backchannel via
> 	  BIND_CONN_TO_SESSION."
> 
> 	- 18.34.3: "If, when the client ID was created, the client opted
> 	  for SP4_NONE state protection, the client is not required to
> 	  use BIND_CONN_TO_SESSION to associate the connection with the
> 	  session, unless the client wishes to associate the connection
> 	  with the backchannel."
> 
> That means that currently if the client attempts to reconnect (e.g. to
> resend a timed-out rpc), it will see SEQ4_STATUS_CB_PATH_DOWN_SESSION
> set on future SEQUENCE replies.

Agreed, however in this case the BIND_CONN_TO_SESSION can be treated as
an optimisation. We should fix it soon, but as long as the existing
clients handle the path down error correctly (which we do by starting a
recovery thread, then resetting the session), then we are able to
function.

IOW: This is something that was on our 'B' list of items to complete
(i.e. after basic session+pnfs functionality)...

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: 4.1 client reconnect bug

[J. Bruce Fields]

On Mon, Oct 17, 2011 at 02:57:52PM -0700, Trond Myklebust wrote:
> On Mon, 2011-10-17 at 17:04 -0400, J. Bruce Fields wrote: 
> > Following up on a pub conversation from a couple weeks ago:
> > 
> > The client apparently assumes that (in the absence of state protection)
> > sending a SEQUENCE over a new tcp connection to the server automatically
> > associates the new tcp connection with both the forechannel and
> > backchannel of the session.
> > 
> > The server currently assumes that the new tcp connection should be
> > associated only with the forechannel.
> > 
> > RFC 5661 sides with the forechannel-only convention:
> > 
> > 	- 2.6.10.6.2: "If the client wants to use additional connections
> > 	  for the backchannel, then it needs to call
> > 	  BIND_CONN_TO_SESSION on each connection it wants to use with
> > 	  the session."
> > 
> > 	- 2.10.13.1.2: "If the connection that was lost was the last one
> > 	  associated with the backchannel, and the client wants to
> > 	  retain the backchannel and/or prevent revocation of recallable
> > 	  state, the client needs to reconnect, and if it does, it MUST
> > 	  associate the connection to the session and backchannel via
> > 	  BIND_CONN_TO_SESSION."
> > 
> > 	- 18.34.3: "If, when the client ID was created, the client opted
> > 	  for SP4_NONE state protection, the client is not required to
> > 	  use BIND_CONN_TO_SESSION to associate the connection with the
> > 	  session, unless the client wishes to associate the connection
> > 	  with the backchannel."
> > 
> > That means that currently if the client attempts to reconnect (e.g. to
> > resend a timed-out rpc), it will see SEQ4_STATUS_CB_PATH_DOWN_SESSION
> > set on future SEQUENCE replies.
> 
> Agreed, however in this case the BIND_CONN_TO_SESSION can be treated as
> an optimisation. We should fix it soon, but as long as the existing
> clients handle the path down error correctly (which we do by starting a
> recovery thread, then resetting the session), then we are able to
> function.
> 
> IOW: This is something that was on our 'B' list of items to complete
> (i.e. after basic session+pnfs functionality)...

OK, I think that makes sense.

--b.