From: Spencer Shepler (shepler@eng.sun.com)
Date: 08/22/02-12:09:32 AM Z
Date: Thu, 22 Aug 2002 00:09:32 -0500 From: Spencer Shepler <shepler@eng.sun.com> Subject: Re: bumping the seqid on which errors? Message-ID: <20020822050932.GV100579@dhcp-uaus08-128-212.sun.com> On Wed, Noveck, Dave wrote: > > > The same goes for SERVERFAULT. It is another catch all error > > for the server and may point to a resource like issue that > > prevents the server from tracking the sequence id. > > Unsure about this one. If servers could do part of the operation > and then return SERVERFAULT, then they should record what they > did and bump the seqid, so that we can sanely deal with > retransmissions. If you know that when SERVERFAULT is returned, > nothing has *really* happened, then not incrementing is fine. > > I guess I would lean to having this one increment the seqid. > If your server is a state in which something failed and isn't sure > what and it is unable to record information about what just happened, > but it feels perfectly able to continue processing new requests, > then somebody should put it out of its misery. Let the client > at least see a clean reboot. I don't have a strong opinion about this case since we have the RESOURCE error and this error is supposed to be a catchall for very bad things on the server. This just means that the server may be implemented to return RESOURCE when it has an error and is too lazy to increment the seqid. > > In the cases of NOFILEHANDLE/BADHANDLE, it doesn't seem > > reasonable to ask the server to continue processing a request > > because the client has given it a malformed request. In fact, > > there may be a malicious client out > > there that may be able to authenticate requests to the server > > but has no access to the server's namespace. With the current > > requirement, it would still be able to obtain server resources > > by the tracking of a seqid for an openowner for a request that > > never used a PUT*FH operation before an OPEN. > > If you go down this path, it is hard to know where to draw the > line. What about case in which the current file handle for an > open is not a directory? That seems to be a "bad" current > filehandle for an OPEN in a certain sense. Well, for BADHANDLE, the server has the opportunity to do any consistency checks at PUTFH, RESTOREFH so it has the choice of erroring the COMPOUND at that point and not getting to a potential OPEN, LOCK operation in the sequence. So BADHANDLE can be left out. > As far as the malicious client, he could do PUTROOTFH/OPEN. > That gives him a valid current fh which is a directory. It > may fail since he can't guess the name of a file in the root > directory (and there may be only sub-directories), but it still > will increment the seqid, unless you are prepared to expand the > don't-increment-seqid-on-this-error class a whole lot more. Okay. I will change it to stupid-client. It is too stupid to build requests correctly because of a bug and keeps sending them to the server without an appropriate PUT*FH operation. This consumes resources on the server. I suppose it is not a big deal since the server can eventually timeout the open_owner information since the sequence will never be confirmed in the stupid-client case but it is still resource consumption. > > any humble opinions? > > My humble opinion is that we should add BADXDR and RESOURCE and > not the others. I agree with BADXDR and RESOURCE and am willing to give in on BADHANDLE and SERVERFAULT. I would like to see NOFILEHANDLE added to the list for "no seqid increment". -- Spencer
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:16 AM Z CST