On Mon, Apr 20, 2020 at 5:20 PM Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > On Mon, 2020-04-20 at 15:35 -0400, Olga Kornievskaia wrote: > > On Mon, Apr 20, 2020 at 3:02 PM Trond Myklebust < > > trondmy@xxxxxxxxxxxxxxx> wrote: > > > On Mon, 2020-04-20 at 10:59 -0400, Olga Kornievskaia wrote: > > > > > > > > On Mon, Apr 20, 2020 at 10:53 AM Olga Kornievskaia < > > > > olga.kornievskaia@xxxxxxxxx> wrote: > > > > > Yes we are consistent in requesting to same connection to with > > > > > the > > > > > same channel binding, but we don't send BIND_CONN_TO_SESSION as > > > > > the > > > > > first thing on the "main" connection (ie connection that cared > > > > > the > > > > > CREATE_SESSION and was bound to fore and back channel by > > > > > default). > > > > > When that connection is reset, the first thing that happens is > > > > > the > > > > > client re-sends the operation that was not replied to. That has > > > > > a > > > > > SEQUENCE and by the rule the server binds that connection to > > > > > the > > > > > fore channel only (and sets the callback being down). We then > > > > > send > > > > > BIND_CONN_TO_SESSION and request FORE_OR_BOTH where this has > > > > > already been bound to FORE only. > > > > > > > > > > > > > How about this: before we send BIND_CONN_TO_SESSION with > > > > fore_or_both, we somehow always reset the connection (maybe you > > > > were > > > > suggestion that already and i wasn't following). > > > > > > No. I didn't realise that we were being automatically set to just > > > the > > > fore channel. However as I said earlier, the spec says that the > > > server > > > MUST reply with NFS4ERR_INVAL in this case. It is not allowed to > > > just > > > return NFS4_OK and silently set the wrong channel binding. > > > > How's this: > > client sends BIND_CONN_TO_SESSION with FORE_OR_BOTH, server select > > FORE channel. connection breaks before the reply gets to the client. > > Client resends. Is the server suppose to now fail with ERR_INVAL? > > > > There actually is such a thing between demand and request. FORE and > > BACK are demands and FORE_OR_BOTH and BACK_OR_BOTH are requests. The > > spec writes only about demands and not the requests. I believe that's > > intentional because BIND_CONN_TO_SESSIOn doesn't have a sequence and > > not protected by reply session semantics. > > OK. However if we take that interpretation, then the question is why > would the server downgrade our FORE_OR_BOTH to FORE and what is the > point of the client even retrying at all in that case? As far as I can tell, the client behaves improperly. It shouldn't have sent an operation on a new connection before sending BIND_CONN_TO_SESSION. > The server can always reject the client's back channel creation > attempt, but doing so has consequences: it means there is no way to > hand out delegations or layouts. So I'm confused by the concept of a > server that sets SEQ4_STATUS_CB_PATH_DOWN or > SEQ4_STATUS_CB_PATH_DOWN_SESSION, but then doesn't allow the client to > set a back channel. Because we can't guarantee that BIND_CONN_TO_SESSION happens as the first operation, I think the solution is for the transport that will do FORE_OR_BOTH request, the client must reset the connection first? Would that be acceptable? > > -- > Trond Myklebust > Linux NFS client maintainer, Hammerspace > trond.myklebust@xxxxxxxxxxxxxxx > >
