Okay, no problem. I'll fix the not-colliding-at-all issue. As for the header issue, I can fix that too by just comparing the first 72 bytes instead of the whole lot - is there any situation that needs the equals method to take this random part of the header into account? If not, I can just change the equals method. If there is, I'll make a new method - 'isSameKey'?
Bug filed: https://bugs.freenetproject.org/view.php?id=324 Dave On Friday 21 April 2006 18:31, Matthew Toseland wrote: > On Thu, Apr 20, 2006 at 02:49:11AM +0100, Dave Baker wrote: > > Hi, > > > > So I've just spent a while tracking down why KSKs and SSKs don't collide, even > > if you insert different data. The answer is that in > > MultiPutCompletionCallback, onFailure gets called, but doesn't complete the > > request because it's still waiting on some blocks. onSuccess then gets called > > and so it returns success and tells the client that everything went fine. > > This could be fixed by changing the: > > > > complete(null); > > > > (line 40), to: > > > > complete(this.e); > > Suggest you fix it. > > > > Which would consider any exception which it may have been given earlier. I'm > > happy to change this, but I'm not really sure whether this is a mistake or by > > design, since there is a certain degree of sense in reporting success when > > the onSuccess method is called, even if a failure occurred in the past. Note > > that, as far as I can tell, this only applies to collisions and cancellations > > - other errors (RNFs and the like - I assume all the nonfatal ones) are > > handled differently. > > > > The second problem, however, is that nodes always report a collision, even if > > the data is the same. After some probing, it turns out this is because the > > last 64 bytes of the SSK headers are different between the block from the > > data store and the block being inserted (see 'equals' in SSKBlock.java). I > > gather from the comments in SSKBlock.java that these are signatures on the > > rest of the hash, so I'm confused as to how they can be different when the > > other 72 bytes are identical. This part I could use some advice on. Are they > > meant to be the same, or is there some reason why they'll differ? > > Ah. DOH. Yeah, this needs to be handled specially... the signatures are > different because they incorporate a random element. We need to compare > everything except for the signatures (while still checking the sigs). > > Please file a bug for this. :) > > > > Sorry for the slightly lengthy email! > > > > > > Dave (dbkr) > -- > Matthew J Toseland - toad at amphibian.dyndns.org > Freenet Project Official Codemonkey - http://freenetproject.org/ > ICTHUS - Nothing is impossible. Our Boss says so. >
