Date: Sun, 12 Apr 2009 14:56:57 +0100 From: Doug Rabson <dfr@rabson.org> To: Robert Watson <rwatson@freebsd.org> Cc: Rick Macklem <rmacklem@uoguelph.ca>, Julian Elischer <julian@elischer.org>, freebsd-arch@FreeBSD.org Subject: Re: getting a callback ip address for nfsv4 client Message-ID: <C8A9F5A9-9B82-43A5-818A-3771B1B25CC7@rabson.org> In-Reply-To: <alpine.BSF.2.00.0904121323220.19879@fledge.watson.org> References: <Pine.GSO.4.63.0903301733120.17182@muncher.cs.uoguelph.ca> <alpine.BSF.2.00.0904051826550.12639@fledge.watson.org> <49D98461.4000002@elischer.org> <alpine.BSF.2.00.0904061143190.34905@fledge.watson.org> <Pine.GSO.4.63.0904061132190.19343@muncher.cs.uoguelph.ca> <BE45DEE0-8D98-4B32-B48A-4D86834DD6E2@rabson.org> <alpine.BSF.2.00.0904121323220.19879@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 Apr 2009, at 13:24, Robert Watson wrote: > On Sun, 12 Apr 2009, Doug Rabson wrote: > >> While the RPC code doesn't currently expose the socket or local >> address, I don't think there would be many problems in adding a >> client control operation to get the local address. Its not a good >> idea to allow access to the actual socket since that will change >> over reconnects. In theory, the local address may also change over >> reconnects but that seems less likely to be a problem. Also, the >> reconnect machinery doesn't actually create the connection until >> the first RPC so some care would be needed to account for that. > > This was pretty much what I had in mind: do an initial no-op, then > query the local address from the RPC layer. The question then is, > when do you requery the address, and I guess an event is needed from > the RPC layer so that the NFS layer knows to re-query and update the > server's callback address (I assume that's allowed?). There is no need for an initial no-op - the code in sys/rpc/clnt_rc.c can connect the socket on an address query as well as on the first RPC. I'm less sure about how to handle address changes, if at all. I don't think the NFSv4 spec says anything on the matter. In NFSv4.1, callbacks are multiplexed onto the same connection as for regular forward RPCs so the problem will eventually go away.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C8A9F5A9-9B82-43A5-818A-3771B1B25CC7>