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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20060421/6578460c/attachment.pgp>
