Subject: Another sequence id issue

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 14 Nov 1999 09:42:43 -0800

I came up with the following while trying to come up
with a solution for the problem of the server being 
unable to reclaim storage being used to store sequence
id's.  (In an earlier reply to Neil Brown, I had 
promised to come up with a simple solution for this,
but each time I try, it keeps eluding me).

The issue involves a client sending a request that
requires a sequence id.  How does it get it?  For
whatever object represent the lock owner, (e.g.
the proc structure), there has to be a list of 
server that the given lockowner has presented
itself to and for each a current sequence id.
So you have to search down this list and find the
associated id, increment it and send it.  If the
server we want to communicate with is not in the
list, we add it in with a sequence number of zero
and send that.

The problem is that this list has to be organized 
by server and not by mount point.  So, if we have
two mount points that the client knows about
and a given process opens files in both, the 
same sequence id stream must be used.  

So the problem is how do you determine whether
two client file systems designate the same 
server?  You can compare the IP addresses but
I believe that that isn't adquate because of
multi-homed servers, etc.  I know that we use
clientid, in part, because we can't simply allow
the server to figure out where requests are 
coming from by simply using the source IP
address.  As far as I can see, this issue is
precisely the same.  Do we need a serverid
that we can can use to see if two client mounts
are served by the same server?

---

From: Mike Eisler <[email-masked]>
Date: Mon, 15 Nov 1999 09:06:30 -0800 (PST)

SETCLIENTID's arguments are:

struct cid {
             opaque          verifier[4];
             opaque          id<>;
};

Rather than add a server id, if the client uses a unique verifier/id pair in
the SETCLIENTID request to each unique server address, this forces the server
to return unique clientds. This suggests that a fixed length 4 byte verifier in
the SETCLIENTID arguments is inadequate. I suggest making it variable length,
and adding appropriate verbiage to the specification to account for
the scenario you described.

I'm still thinking about the previous seqid problem. I have this vague notion
that the tcp/ip protocol is stateful, it has sequence numbers, and it doesn't
have this problem, and so the answer lies there somehow.

	-mre