On Tue, Mar 29, 2022 at 06:17:29PM -0700, dai.ngo@xxxxxxxxxx wrote: > > On 3/29/22 5:12 PM, J. Bruce Fields wrote: > >On Tue, Mar 29, 2022 at 02:45:28PM -0700, dai.ngo@xxxxxxxxxx wrote: > >>This does not prevent the courtesy client from doing trunking in all > >>cases. It is only prevent the courtesy client from doing trunking without > >>first reconnect to the server. > >> > >>I think this behavior is the same as if the server does not support courtesy > >>client; the server can expire the courtesy anytime it wants. If the > >>courtesy client reconnected successfully then by the time nfsd4_create_session/ > >>find_confirmed_client is called the client already becomes active > >>so the server will process the request normally. > >I'm not sure what you mean here. All a client has to do to reconnect is > >succesfully renew its lease. > > For 4.1 the client renews its lease via the SEQUENCE, either stand-alone > or in a compound. Once the SEQUENCE completes successfully then the > subsequent CREATE_SESSION is processed normally. However, if the client > did not send the SEQUENCE first then server returns BAD_SESSION for the > CREATE_SESSION request. > > > That doesn't necessarily require calling > >CREATE_SESSION again. > > > >>Also to handle cases when the courtesy client reconnects after it was in > >>EXPIRED state, we want to force the client to recover its state starting > >>with EXCHANGE_ID so we have to return BAD_SESSION on CREATE_SESSION request. > >The client should not have to send EXCHANGE_ID. > > For 4.1 the expired courtesy client must send EXCHANGE_ID to reconnect > to start new session. I don't see how the *expired* courtesy client can > access the export again without sending the EXCHANGE_ID. Attached is the > pcap that shows how the courtesy client recovers once it's in > CLIENT_EXPIRED state. Oh, sorry, sure, we're talking about an actual expired client. That's fine. --b.
