[AFS3-std] extended callback cancellation, please discuss

Tue, 06 May 2008 11:57:38 -0400

-----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-----