From: cburnett@us.ibm.com
Date: 06/24/02-03:02:00 PM Z
From: cburnett@us.ibm.com
Subject: Re: Issue 86 -- Now or never
Message-ID: <OF07E25BBF.A4DB63A9-ON85256BE2.006D3103@us.ibm.com>
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 cburnett@us.ibm.com)
Spencer Shepler
<shepler@eng.sun.com> To: "'nfsv4-wg@sunroof.eng.sun.com'" <nfsv4-wg@sunroof.eng.sun.com>
Sent by: owner-nfsv4- cc:
wg@sunroof.eng.sun.com 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
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:53 AM Z CST