From: Kendrick M. Smith (kmsmith@umich.edu)
Date: 02/01/01-01:17:14 PM Z
Date: Thu, 1 Feb 2001 14:17:14 -0500 (EST) From: "Kendrick M. Smith" <kmsmith@umich.edu> Subject: RE: Stateid and seqid Message-ID: <Pine.SOL.4.10.10102011411580.15381-100000@seawolf.gpcc.itd.umich.edu> On Thu, 1 Feb 2001, Noveck, Dave wrote: > Sergei Klyushin wrote: > > Sorry for misunderstanding. I've very ease used "request". > > My implementation is operation oriented also. As I understand idea of > seqid > > is to guarantee sequence of OPEN,LOCK,UNLOCK,CLOSE, in another words > > OPERATIONS > > that take seqid, and reply must be stored for such OPERATIONS, but not for > > the whole request > > So that leaves Kendrick with the other interpretation, unless I've > misunderstood him too. Anybody else have a server that does this > one way or the other? I suppose if there is a third interpretation > out there, we'd better hear about that too. :-( We interpreted the spec as saying that the request-level caching should be done, but operation-level caching makes a lot more sense (and also seems necessary for correctness in all cases), so if everyone agrees that operation-level caching is correct, we'll switch to operation-level caching. (The only server implementation we haven't heard from yet is Sun's.. correct?) On Tue, 30 Jan 2001, Noveck, Dave wrote: > Sergei Klyushin wrote: > > So, you don't store stateid (or even full request) for reply message, > > but you are based > > only on seqid = stored_seqid? How you could be sure, that it's real > > replay, but not logical error? > > I want to be sure at this point, that I understand replay correctly: > > for me it's real > > retransmission of exactly the same package. Is it true? > > Right now, I only check the seqid and operation. I might save > more information if I find that there are broken clients that > are sending a seqid that matches a previous request with a > different request. Saving the whole operation seems excessive > to me, particurlay given OPEN which can be fairly large. If > this really turns out to be a problem (and I kind of doubt it > will), then maybe saving a 64-checksum of the operation seems > reasonable. > > The issues are similar to the normal reply cache. I don't know > what other systems do, but there we match on transaction id and > then check a few other items. We certainly don't save and check > the entire request. I doubt many systems do. We currently store the entire request because we inherited this behavior from the Linux NFSv2/v3 server, which does store requests in its replay cache. On the other hand, it seems to be safe to store only the RPC XID (which is what FreeBSD does, at least), so we'll probably eventually move toward an xid->response cache (probably not before Connectathon, though.. my mental list of "things to do before Connectathon" is reaching frightening proportions!) Kendrick
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:28 AM Z CST