Date: Mon, 6 Apr 2009 11:56:20 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Robert Watson <rwatson@FreeBSD.org> Cc: Julian Elischer <julian@elischer.org>, freebsd-arch@FreeBSD.org Subject: Re: getting a callback ip address for nfsv4 client Message-ID: <Pine.GSO.4.63.0904061132190.19343@muncher.cs.uoguelph.ca> In-Reply-To: <alpine.BSF.2.00.0904061143190.34905@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.) rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0904061132190.19343>