Date: Sun, 12 Apr 2009 12:42:24 +0100 From: Doug Rabson <dfr@rabson.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Robert Watson <rwatson@FreeBSD.org>, Julian Elischer <julian@elischer.org>, freebsd-arch@FreeBSD.org Subject: Re: getting a callback ip address for nfsv4 client Message-ID: <BE45DEE0-8D98-4B32-B48A-4D86834DD6E2@rabson.org> In-Reply-To: <Pine.GSO.4.63.0904061132190.19343@muncher.cs.uoguelph.ca> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6 Apr 2009, at 16:56, Rick Macklem wrote: > > > On Mon, 6 Apr 2009, Robert Watson wrote: > >> On Sun, 5 Apr 2009, Julian Elischer wrote: >> >>>> One possibility is to connect() a socket to the server address, >>>> then call getsockaddr() to query what address the network stack >>>> is using. If the connection completed, then the address could at >>>> least send packets to the server, even if it isn't reachable from >>>> the server. >>>> (Obviously, kernel versions of the above...) >>> we ended up with him doing "whatever the connect code would have >>> done" since as he is in fact inside the kernel, he can just do the >>> same.. >> >> I figured that if the RPC layer was going to make a connection >> anyway, we could just query the RPC layer and ask it what address >> it had used. However, if the decision needs to be made earlier >> than that, then that doesn't make as much sense. This would mean >> NFS could avoid knowing about routes and interfaces, and just know >> about sockets and addresses. >> > > I just took a quick look at Doug's RPC code and the socket doesn't > seem to be exposed to the client side by the rpc layer, so I think > that rtalloc1() is probably easier? I'd also be worried about > knowing when the socket > pointer is valid and in a connected state. (The rtalloc1() code only > uses the > one path rt->rt_ifa->ifa_addr after sanity checking that the > pointers aren't null, so I don't think it will be difficult to > maintain. It does imply > that the code knows the route locking rules, but that just means it > uses RTFREE_LOCKED(rt), so as long as that macro keeps working, it > should > be ok, I think.) 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BE45DEE0-8D98-4B32-B48A-4D86834DD6E2>