Ok, I see your point - yes, it's better that pynfs has "unusual but still RFC-compliant" behaviour to catch the real bugs. I will check how this behaviour (using seqid=0 or even something else for EXCHANGE_ID) can be controlled from the caller side if we want to override it. P.S. Since the very 1st operation after NFS4 NULL is EXCHANGE_ID - it should be only single operation (client can't send few ECHANGE_ID because clientowner is only one per mount) and next CREATE_SESSION can't be sent until EXCHANGE_ID is replied from the server. So the use-case of 'any of the first 128 rpcs were out of order' is just a theoretical one and probably not possible in practice. And thanks for handling the patch! volodymyr. On Fri, Oct 1, 2021 at 6:48 PM J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Fri, Oct 01, 2021 at 05:38:45PM +0300, Volodymyr Khomenko wrote: > > > The seq_num field can start at any value below MAXSEQ > > Yes, that's the statement I haven't found before in RFC... > > Probably we also need to write a test starting the seq_num from a big > > value (more than SEQUENCE_WINDOW) > > to make sure that it is really implemented properly without > > 'is_inited' flag (so what's the initial value?). > > > > However I still propose to keep the default behaviour of pynfs to be > > the same as for linux NFS4 client. > > I think the caller can change it when needed (to 0 or whatever > > needed), but the default value should be good... > > That's what I'd choose if I were writing a "real" client. Everybody > already tests with the Linux client, so its behavior is a safe bet. > > But I'd usually prefer a test client do different things than the client > everyone already tests with. > > Like I say, the seqid=0 already caught a bug in my server, so I'm a fan. > > (And it's a bug that would also trigger if any of the first 128 rpcs > were out of order. But that would probably manifest as some user > reporting "once in a blue moon my krb5 mounts hang" and I think it would > take a while to get from that report to this bug as the root cause. So > I'm glad pynfs hit it....) > > --b.
