From owner-freebsd-arch@FreeBSD.ORG Sun Apr 12 13:57:28 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0C0F106566B; Sun, 12 Apr 2009 13:57:28 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (router.rabson.org [80.177.232.241]) by mx1.freebsd.org (Postfix) with ESMTP id 648038FC16; Sun, 12 Apr 2009 13:57:28 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc] (unknown [IPv6:2001:470:909f:1:21b:63ff:feb8:5abc]) by itchy.rabson.org (Postfix) with ESMTP id D47EC5C60; Sun, 12 Apr 2009 14:57:20 +0100 (BST) Message-Id: From: Doug Rabson To: Robert Watson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 12 Apr 2009 14:56:57 +0100 References: <49D98461.4000002@elischer.org> X-Mailer: Apple Mail (2.930.3) Cc: Rick Macklem , Julian Elischer , freebsd-arch@FreeBSD.org Subject: Re: getting a callback ip address for nfsv4 client X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 13:57:29 -0000 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.