From: Spencer Shepler (shepler@eng.sun.com)
Date: 05/30/02-12:33:18 PM Z
Date: Thu, 30 May 2002 12:33:18 -0500 From: Spencer Shepler <shepler@eng.sun.com> Subject: Re: Why does CB_* require a return path? Message-ID: <20020530173318.GD101252@sheplerathome.eng.sun.com> On Thu, Alfred Perlstein wrote: > I've been studying the spec for a while and something has been bothering > me about delegations and the associated callbacks. > > Specifically: > > Because callback RPCs may not work in all environments (due to > firewalls, for example), correct protocol operation does not depend > on them. Preliminary testing of callback functionality by means of a > CB_NULL procedure determines whether callbacks can be supported. The > CB_NULL procedure checks the continuity of the callback path. A > server makes a preliminary assessment of callback availability to a > given client and avoids delegating responsibilities until it has > determined that callbacks are supported. Because the granting of a > delegation is always conditional upon the absence of conflicting > access, clients must not assume that a delegation will be granted and > they must always be prepared for OPENs to be processed without any > delegations being granted. > > Ok, since afaik NFSv4 works over a stream (read: TCP) channel, why > not send the callbacks back over this same channel insread of > forcing complications on the client side for handling incoming > requests, fixing firewall rules and the overhead associated with > maintaining an additional connection. See http://www.nfsv4.org/rfc3010updates/issues.html Issue 145 captures (briefly) the issue you point out here. > There has to be some way to utilize the channel in a bidirectional > manner to squelch this potentially painful implementation detail. > > I mean don't we want strong cache coherency as often as possible? As a point of correctness, delegation does not provide strong cache coherency but rather provides the client a guarantee that no other client will be accessing the file concurrently. The server is required to recall the delegation when there is a conflict with another client. The server is also able to recall the delegation at will for whatever reason it thinks is reasonable. Therefore, the client must not depend on delegations and can only rely on the traditional NFS cache consistency mechanisms. > I know this causes some nits for SunRPC, however if the protocol > was modified slightly this could be done, basically why attaching > a direction bit to each message that goes over the wire. The RPC definition already has a CALL/REPLY mechanism. Therefore it is possible that a client could receive CALLs on the connection it uses for server communication. However, there are additional issues that have not been discussed with respect to this issue that will need to be resolved. Some of the easy ones are: will the RPCSEC_GSS in the reverse call direction need to negotiate in the same way that the regular CALL mechanism does. I believe it will and the client will need to be prepared for this. If TCP is used, the connection may have been closed by either the client or server thus making unavailable the callback path for the server. It has been suggested that the server just postpone callbacks until the client reestablishes a connection with the server since it must do so to RENEW the state. However, there may be issues of the server identifying correctly which connections are associated with the original delegation. This also will get in the way of CB_GETATTR calls where the server would like to respond in a reasonable time frame to the original GETATTR that caused the callback to occur. Then there is the issue of non TCP transports. If a client were to implement a the required congestion control over UDP then what is the callback path for the server. Traditional NFS clients that use UDP use a variety of UDP ports and the server must choose one for the callback. Obviously, we could limit the use of the suggested callback modificatin to TCP or the like to resolve this but it is still a choice. For these reasons, I believe that this issue will be closed as no action for the current update of RFC3010 but should be discussed for future minor versions of NFSv4. As we gain experience with the delegation implementations and the callbacks, it may become imperative that we implement/define this mechanism clearly. -- Spencer
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:45 AM Z CST