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" <[email protected]> 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 _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
