-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 There has been some IRC discussion about cancellation in extended callbacks, between myself and Jeff Altman so far.
This discussion somewhat presupposed my last xg draft, in which notification messages are specified to not effect cancellation, except those of type 'AFSCB_Event_Cancel.' Discussion is currently on two tracks: 1. cancellation should indicate reason for cancellation (eg, volume offline, callback gc, several others). so far there would be consensus here, except for overlap with #2: 2. cancellation as a separate message (I originally proposed separate, Jeff Altman favors cancellation flag [and I would add, apparently also need reason] to all messages Discussing these together, Without other feedback, I would have added a set of constants representing reasons for cancellation, and added a member to a new AFSCancelData structure, making this the union data type for cancel messages. The semantics here as I intuit them are, if the fs wishes to cancel a callback, the client has no further need for information about the object being revoked. Message types are more orthogonal (to me, cleaner, initial intuition). Jeff's approach connotes "send the change and indicate that the change is the last notification the client is going to receive." The client should have any info fs is "aware of" including a change that happens at the instant it is going offline, or moving the volume, or whatever. If we did Jeff's approach, is there still a role for cancellation where we don't tell client other information--that we may not prefer it use to make inferences? There feels like to me maybe a bit a of a reversal hidden there, of fs and client roles in cache management, but maybe I'm reading in. There's some IRC traffic--I'll paste it in below. Note, I started to be convinced, then decided I'm not sure. Matt (started in private irc) (10:41:45 AM) MattBenjamin: I wanted to chat about your other point from last xg file--that clients should be able to cancel a callback with any messages. I wanted to ask whether that req. would not be satisfied by the stipulation that the protocol allows the FS to send a cancellation msg whenever it wants (10:42:17 AM) MattBenjamin: no, though it's out there. I think it works, but haven't pounded it hard like i did my connection pool (10:43:15 AM) MattBenjamin: ie, if the effect of a message is cancellation, the fs might want to just send cancel (10:43:42 AM) secureendpoints: I think you want to avoid requiring a second "I am canceling the callback registration" message. Just have a flag in the message that means "if set the callback registration has been removed". (10:44:03 AM) MattBenjamin: do you see a use for other flags, in future? (10:45:01 AM) secureendpoints: don't know but if its there we might find a use. they would have to be used only when the client is known to support the extension (10:45:09 AM) MattBenjamin: right (10:45:54 AM) MattBenjamin: my thought had been, that if the fs is going to cancel the callback, there is no need to send information messages--so is it not possible that having a cancel message, and using it in that case, is slightly more efficient? (10:46:09 AM) secureendpoints: the standalone "cancel" message must indicate why the message is being sent. "callback recycling", "server going down", etc. (10:46:51 AM) MattBenjamin: i see. (10:47:13 AM) secureendpoints: "volume moved" (10:47:41 AM) secureendpoints: "volume offline" (10:48:11 AM) MattBenjamin: (I'll collect these cases--send any more you can think of) (10:48:39 AM) secureendpoints: look through all of the errors that the file server can produce. that will give you ideas. (10:49:00 AM) MattBenjamin: (check) but regarding the cancel point, do you still think you'd prefer to have fs send information-bearing msg when callback is to be cancelled? (10:49:18 AM) MattBenjamin: (other than reason for cancellation) (10:50:03 AM) secureendpoints: if the data has changed then the file server needs to tell the client that. (10:50:50 AM) MattBenjamin: ok, then I'll add a flagset to the ext callback structure (10:51:09 AM) secureendpoints: my goal here is to permit the clients to be as optimal as possible. (10:51:41 AM) secureendpoints: if the directory changed because it has a new entry, send the entry to the client so the client doesn't have to re-read the entire directory. (10:52:45 AM) MattBenjamin: sure--that's comparable to the most important case for file data (10:52:47 AM) secureendpoints: if the file server is breaking the callback registration early, tell the client why so that client can decide to try a different replica if needed (moved discussion to #openafs, pasted text of above) (11:07:22 AM) MattBenjamin: secureendpoints: I sense that cancellation, ~ now with reason, should be its own message. (From above spam, the alternative might be a message like "entry added to directory, name is 'myfile', by the way callback is cancelled, 'volume offline') (11:07:47 AM) summatusmentis left the room (quit: "This computer has gone to sleep"). (11:07:57 AM) MattBenjamin: doesn't that make messages more orthogonal? (11:08:40 AM) MattBenjamin: because if the fs knows it wants to cancel, it doesn't need to tell client about myfile--so why bother? (11:09:30 AM) secureendpoints: I don't understand why you keep saying that the file server does not need to tell the client about a change that it is aware of. (11:09:36 AM) MattBenjamin: this doesn't hide info from client that it needs--in the cases where it is allowed to use knowledge of myfile, it will just get the createfile message (11:09:46 AM) MattBenjamin: I'm not. I'm saying it should. (11:10:14 AM) MattBenjamin: I'm saying, sending that info isn't cancellation (11:10:18 AM) MattBenjamin: . (11:11:39 AM) secureendpoints: what I am saying is "send the change and indicate that the change is the last notification the client is going to receive" - -- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIIH/xJiSUUSaRdSURCPYCAJ0YPx4Hd6YQD+cNcK0bIeE4YS0gBACfeWub JavaDEKTTKtSV9oZzpZqTrE= =6olL -----END PGP SIGNATURE----- _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
