Subject: Re: Issue 86 -- Now or never

From: [email-masked]
Date: Mon, 24 Jun 2002 15:02:00 -0500

I would vote with Dave to add a new "serverId" field to the SETCLIENTID
operation. Dave's suggestion of a 32-bit value should be sufficient. The
DFS client did something similar during its server context initialization.
This should provide the client a more flexible alterative in choosing
efficient values to quickly find the correct stateid instance. Overloading
the RPC packet header fields seems undesirable.

Carl

Carl Burnett
AIX Kernel Architecture - Distributed File Systems
(512) 838-8498, TL 678-8498
(please reply to [email-masked])

                      Spencer Shepler                                                                                                          
                      <[email-masked]>          To:       "[email-masked]'" <[email-masked]>                 
                      Sent by: owner-nfsv4-          cc:                                                                                       
                      [email-masked]         Subject:  Re: Issue 86 -- Now or never                                                    

                      06/21/2002 02:26 PM                                                                                                      
                      Please respond to                                                                                                        
                      spencer.shepler                                                                                                          

On Fri, Noveck, Dave wrote:
> 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.

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

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 24 Jun 2002 15:15:55 -0500

Okay, I think we are in agreement that it is reasonable and useful to
have an identifier available for callback differentiation. 

However, I would like to clarify Dave's suggestion that this value
will be provided by the client and the server will dutifully pass it
back on CB_* calls.  This identifier is not a server provided value
and does not help in the differentiation of servers (in the case of a
multi-homed server).

In any case, I will add this modification to the next version of the
document (should be out this evening).

Spencer

-- 
Spencer