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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html