From: Brent (brent@eng.sun.com)
Date: 09/14/01-04:45:16 PM Z
Message-ID: <3BA27A6C.6489923D@eng.sun.com> Date: Fri, 14 Sep 2001 14:45:16 -0700 From: Brent <brent@eng.sun.com> Subject: Re: Delegation callbacks proposal Neil Brown wrote: > The NFSv4 protocol has two situations where a network address needs > to be communicated. > > There is this situation, which uses a netid and a "universal address", > and there is the fs_location attribute that uses a "server" name, > to be looked up in the DNS or using inet_addr(3). > I always thought it was unfortunate that you couldn't specify a port > number in the fs_location field, and thus have multiple servers running > with the one IP address, possibly serving different filesystems with > vastly different implementations (though I cannot actually find a > concrete use for this. "automounters" come to mind, as they run an > NFS service on a non-standard port, but they don't make for a strong > argument). It's true that NFS mount commands have a "port" option, and the NFS URL (RFC 2224) allows a port to be specified with the server hostname. One could argue that the replica list should simply be a list of URLs. There are rare instances where there's multiple NFS servers running on a host - though the default one normally lives on the "well known" port 2049. Yes, it's unfortunate that fs_locations doesn't provide a port option. > I note in your proposed solution the sentence: > > "If a dropped connection needs to be re-established, then client or > server must make a best effort to re-establish when needed." > > I'm not sure how the server would re-establish a connection. > Connecting to the client is quite different to sending an RPC request > up the connection that was established by the client (but that is > ofcourse the point). > You could suggest that if the client used a connection oriented > protocol, then it should listen on the same port that it sent the > SETCLIENTID request on. However that assumes that that makes sense in > a protocol-independant sense, and I'm not sure that it does. > As a (somewhat strained) example, imagine connecting to the server > over a Unix domain socket. I don't think that the client's end of the > connection has a name that can be used in a "connect" request by the > server. Right, I'm sure there are cases where the server is unable to restore a connection. The only hope then is that the client detect a failed connection and establish a new one before the server needs it for callbacks. Brent
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:05 AM Z CST