[AFS3-std] rpc refresh: FetchDirectory: discussion only

[Matt W. Benjamin]

Depending on your point of view, this might be increasing the complexity of afs3
messaging, but clearly it would be reducing protocol workload when you
could do it, I agree.  A bit nfsv4 flavored :), but I think it's interesting.
To implement the optimization, the file server needs to rendezvous with the enqueued
notifications (easy), pick off the ones applicable to this host (some cost), and
finally have an efficient mechanism to omit to deliver just these notifications
to this client host, presuming this host isn't the unique recipient (tricky, today).
Design goals for the new host and callback packages...

Matt

----- "Tom Keiser" <tkeiser@sinenomine.net> wrote:

> 
> Actually, I think I see a good opportunity to reduce the messaging
> complexity of afs3: drop an XCB notification vector (and probably a
> "you're caught up now" flag) as an OUT parameter on the RPC.  A file
> server implementing XCB async delivery semantics would then have the
> _option_ of delivering a subset of queued notifications, thus
> potentially eliminating a second round trip, and hopefully
> eliminating
> the posited desire for aborts.  If this works out as well as I
> suspect
> it will, we might eventually want to add such an OUT parameter to
> many
> of the afsint RPCs.
> 
> -Tom

-- 

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309