[nfsv4] Callbacks are dead, long live callbacks!

Nicolas.Williams@sun.com

From: Nicolas Williams <Nicolas.Williams@sun.com>
Message-ID: <20031031204710.GI27412@binky.central.sun.com>
Subject: [nfsv4] Callbacks are dead, long live callbacks!
Date: Fri, 31 Oct 2003 12:47:10 -0800

Here's a proposal to fix the problems with the callback channel, and
even make it go away!

[Pardon the rough presentation syntax below.]

Add one callback channel op (always done with AUTH_NONE):

 - CB_ASKMEWHATIWANT (clientid) -> void;

Add two v4 channel ops (both can return WRONGSEC):

 - WHATDOYOUWANT (clientid) -> ([cb_sequence_id, cb_op_id, cb_args]);

 - IHAVEDONEIT (clientid, cb_sequence_id, cb_results) -> void;

How it works:

 - Encapsulates CB ops in the forward channel.  Servers can ask that
   clients check for CB ops to perform and clients can poll for CB ops
   to perform.

    - Clients that have server-side state that the server might want to
      revoke or recall through callbacks can add the WHATDOYOUWANT
      operation to their every v4 compounds, including RENEW.

    - Servers can use CB_ASKMEWHATIWANT to remind clients to check for
      what the server might want the client to do.

 - Servers can refuse to use in, the CB channel, any CB ops other than
   CB_ASKMEWHATIWANT for v4.x clients that should support these new ops.

 - Clients can protect against abuse (DoS) of CB_ASKMEWHATIWANT by
   throttling standalone calls to WHATDOYOUWANT if the server's response
   to those for N times in a row is empty.

 - IHAVEDONEIT is needed only for CB ops whose return value isn't void.

 - New CB ops can be defined (e.g., for directory delegations), but
   generally would be used only through WHATDOYOUWANT/IHAVEDONEIT.

 - The only unprotected CB ops then is: CB_ASKMEWHATIWANT, which is
   harmless to call unprotected.

 - Servers revoke state if clients fail to respond to CB_ASKMEWHATIWANT
   ops with WHATDOYOUWANT/other ops[/IHAVEDONEIT] v4 op sequences.

 - There's no need for servers to act as GSS-API initiators.

   (CCM-MIC, then, is out of this picture with this.)

 - Polling for locks could be made more efficient: one poll per-client/
   server pair, rather than one poll per-lock.

IMO, this is how v4 should have been from the get go.

Cheers,

Nico
-- 

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4