Subject: RE: [nfsv4] Issue98 - can callback traffic show up on any connection?

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 30 Jul 2006 10:30:23 -0400

BIND_BACKCHANNEL also has the function of setting the callback_program
and callback_ident to be used on callbacks.  In the absence of 
a BIND_BACKCHANNEL, it is not clear what values would be used for
these.

Looking one level deeper, there is really no need, given sessions,
for callback_ident and we could just get rid of it.

As far as callback_program, it seems that this too could be gotten
rid of but we need alternative fixed definition.  The obvious choice,
the NFS program number leads to problems in that if we adopted it,
we could not inspect a request and know whether it was a request 
or a callback.  You could know by the context that if you are the 
client and you get a request it is callback, but if things ever got
misrouted you could have a mess.  What we should have done, is to
make COMPOUND and CB_COMPOUND different procedure numbers, but
we can't do that now.  Maybe we just need to register a specific
program number for this. 

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Sunday, July 30, 2006 10:13 AM
To: [email-masked]
Subject: [nfsv4] Issue98 - can callback traffic show up on any
connection?

http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue98

I'm editing the sessions chapter, and found this
text:
          In fact, the callback channel will be enabled to
          share the same connection as the operations channel.

This implies to me that bi-directional RPC can happen on any connection
bound to the session, regardless whether BIND_BACHCHANNEL is called.

So Issue98 says:

--------------

Can callback traffic show up on any connection?

If so, then why do we need to bind connections to the back channel
(other than for establishing the secinfo4 requirements and RPCSEC_GSS
context for the server's callback to the client)?

If BIND_BACKCHANNEL is an advisory mechanism to tell servers which
connections are preferred by the client for callbacks, there are better
ways (such as a flag in BIND_CONN_TO_SESSION). And we could reduce
BIND_BACKCHANNEL to its function of setting up RPCSEC_GSS contexts for
the callback.

-----------

So are people (really client implementors; yes, they are people too,
even the ones that what POSIX compatibility :-) prepared to implement
fully bi-directional RPC on their clients?
It will vastly simplify the specification, particularily the recovery
section which I'm trying to write. Though has a former RPC/TCP
implementor, think there will be difficulties in doing that. I saw
BIND_BACKCHANNEL as a nice way to side step the issue: client creates a
connection, and hands it to the server for callback use.

I brought this up with Dave Noveck and Spencer. Dave and Spencer agreed.
Dave later noted that call back traffic is not receivavle until
BIND_BACKCHANNEL is invoked.
If that is the model, OK, but BIND_BACKCHANNEL ought to be renamed.

So it seems we have 3 ways to go here:

- any connection can carry call back traffic
- any connection can carry call back traffic, once
  call backs are enabled
- only designates connections can carry call back traffic.

I need to know in order to finish the sessions chapter editing.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Mike Eisler <[email-masked]>
Date: Sun, 30 Jul 2006 07:53:02 -0700 (PDT)

> a BIND_BACKCHANNEL, it is not clear what values would be used for

There's no reason the call back parameters couldn't be established
at CREATESESSION time which is effectively what
NFSv4.0 did. Where NFS4.0 erred in this case was in
using the same operation to set up callback stuff to also
update callback stuff. A separate operation should be used to
update callbacks info. 

> for callback_ident and we could just get rid of it.

Because NFSv4.1 mandates a CB_SEQUENCE at the
beginning of each CB_COMPOUND, you are absolutely
right. This is another artifact of the revious "sessions
are optional" model. I'll get rid of _ident.