Subject: Issue 86 -- Now or never

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 21 Jun 2002 08:08:59 -0700

I've been looking at the remaining issues and trying to focus
on those that might involve an incompatible change to the
.x file.  The window for those is rapidly closing, if it is
still open at all.

My opinion is that that window shuts and locks at the August
bakeoff, so that if we need to do something that needs to 
change the protocol, we should do it now.

Now to issue 86.  The problem is that callbacks do not identiry
the server.  They contains stateid's and filehandles but none
of those are under the client's control.  Servers assign them and
you can't assume they are different on different servers.

The client can deal with this by using distinctive callback
information for each server that it is talking to: either a
different program number or port or combination of those two.
Since the client can deal with this, the existng structure can
be categorized as an annoyance, but I feel it is a big annoyance.
What do the client implementers feel about this?  Should we
just fix this by having the client present a 32-bit quantity
in the SETCLIENTID and have that value be passed by the server 
in the CB_COMPOUND4ARGS?  That minor change would make the 
problem go away.

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 21 Jun 2002 14:26:48 -0500

> in the CB_COMPOUND4ARGS?  That minor change would make the 

Dave,
  We have been able to manage the issue as you suggest by using
various program numbers in the transient range to demultiplex the
callback RPCs.  I am not opposed to making the suggested change; we
would just use the program numbers we are using today as the
identifier.
  Anyone else have a strong opinion?

-- 
Spencer