From: Spencer Shepler (shepler@eng.sun.com)
Date: 08/29/02-05:46:34 PM Z
Date: Thu, 29 Aug 2002 17:46:34 -0500 From: Spencer Shepler <shepler@eng.sun.com> Subject: Re: issue11 - CB_GETATTR/change attribute Message-ID: <20020829224634.GD101444@dhcp-uaus08-128-212.sun.com> On Thu, Mike Eisler wrote: > > TO: > > While the change attribute is opaque to client in the sense that it > has no idea what units of time, if any, the server is counting change > with, it is not opaque in that the client has to treat it as an > integer, and the server has to be able to see the results of the > client's changes to that integer. Therefore, the server MUST encode > the change attribute in network order when sending it to the client, > the client MUST decode it from network order to its native order when > receiving it, and the client MUST encode it network order when > sending it to the server. For this reason, change is defined as an > unsigned integer, rather than an opaque array of octets. > > For the server, the following steps will be taken when providing a > write delegation: > > o On providing a write delegation, the server will cache a copy of > the change attribute. Let this value be represented by sc. > > o The server obtains the change attribute from the client. Let > this value be cc. > > o If the value cc is equal to sc, the file is not modified and the > server returns the current values for change and time_modify > (for example) to the client requesting GETATTR. > > o If the value cc is NOT equal to sc, the file is currently > modified at the client and most likely will be modified at the > server at a future time. The server then uses the current time > to construct attribute values for time_metadata and time_modify. > It uses cc and sc to construct a provisional value > for change, which we will represent as pc, such > that pc is greater than sc, and if cc > sc, pc == > sc (not withstanding the following paragraph). The > server then returns the constructed time_metadata, > time_modify, and pc values to the requestor. > > Furthermore, in the event of another GETATTR > of the delegated file, and the client returns > a cc value that was different than that of > previous CB_GETATTR, the server must take care > to ensure that new pc it constructs and returns > is greater than the previous pc it returned. > This is not necessarily trivially done if the > server constructs change from a high resolution > time_metadata attribute, because the client does > not know how the server constructs change. It is > conceivable that the cc value is greater than the > server's current time. The only requirement for the management of the change attribute with CB_GETATTR to work properly is that the client return a value cc that is sc+1. At each CB_GETATTR, the client does not have to keep returning a value for cc that different from the last value returned. The server only needs to know if unwritten/modified data exists at the client and from this the server can then represent the appropriate attributes as suggested above. Therefore, if we were to restrict what the client returns for a value of change (e.g. cc in the above notation) to either sc or sc+1, then that helps the server a little. The server still needs to manage the value of pc carefully such that it represents to the third party that the file is "changing". Is there an alternate interpretation of how the client should represent the value cc? The reason it had been suggested that it be one value or the other (sc or sc+1) is that this eases the client's implementation of checking for modified data in its cache. -- Spencer
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:18 AM Z CST