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. -Dai
--b.
Attachment:
netpart-reconnect.pcap
Description: Binary data
