From: Brent Callaghan (brent@eng.sun.com)
Date: 05/30/02-12:49:28 PM Z
Message-ID: <3CF66628.8B543EED@eng.sun.com> Date: Thu, 30 May 2002 10:49:28 -0700 From: Brent Callaghan <brent@eng.sun.com> Subject: Re: Why does CB_* require a return path? This was discussed in August last year - the thread beginning here: http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/2001/0488.html IMO it's embarrasing that NFSv4's most useful feature for Internet users (delegation) is useless for anyone that works behind a NAT (most of us). Brent Alfred Perlstein wrote: > > I've been studying the spec for a while and something has been bothering > me about delegations and the associated callbacks. > > Specifically: > > Because callback RPCs may not work in all environments (due to > firewalls, for example), correct protocol operation does not depend > on them. Preliminary testing of callback functionality by means of a > CB_NULL procedure determines whether callbacks can be supported. The > CB_NULL procedure checks the continuity of the callback path. A > server makes a preliminary assessment of callback availability to a > given client and avoids delegating responsibilities until it has > determined that callbacks are supported. Because the granting of a > delegation is always conditional upon the absence of conflicting > access, clients must not assume that a delegation will be granted and > they must always be prepared for OPENs to be processed without any > delegations being granted. > > Ok, since afaik NFSv4 works over a stream (read: TCP) channel, why > not send the callbacks back over this same channel insread of > forcing complications on the client side for handling incoming > requests, fixing firewall rules and the overhead associated with > maintaining an additional connection. > > There has to be some way to utilize the channel in a bidirectional > manner to squelch this potentially painful implementation detail. > > I mean don't we want strong cache coherency as often as possible? > > I know this causes some nits for SunRPC, however if the protocol > was modified slightly this could be done, basically why attaching > a direction bit to each message that goes over the wire. > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.'
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:46 AM Z CST