* Matthew Toseland <toad at amphibian.dyndns.org> [2008-04-15 18:06:02]:
> Is it better to report actual CHKs, or block numbers? Maybe we should do > both? > We would only need block numbers for selective reinsertion (the next logical > step), although there isn't really any good reason not to report CHKs. > Heh... are you sure about that ? A few months ago you changed "when" the top-level-block is inserted to make correlation attacks more costy... and here you don't object to a patch leaking its informations ? The purpose of the patch is clear: they want to insert "some key others clients can find" containing both "a description of what is going to be inserted -aka a filename-" and "the reference to the blocks composing it -their URI" so that other clients can pre-fetch it. Isn't it all you need to make correlation attacks possible? You know which file is going to be inserted: provided you've already got it (which is likely if we are talking of some copyrighted content and you're running after people infringing your copyright) you can pre-compute the URI of its blocks and track who is inserting them. > What about request resuming / finding blocks in the datastore? On starting a > request, we turn off SimpleProgress notification, because most of the time > the request is being resumed from the datastore and therefore we would send > vast numbers of SimpleProgress messages referring to blocks we have already > downloaded. > > This should be dependant on a Verbosity flag. > > Also, your diff is empty. This might be a kmail problem on my end though... It's a problem on your end. > > On Tuesday 15 April 2008 17:51, Jano wrote: > > Hello, > > > > the attached patch adds an URI field to SimpleProgress messages which > reports > > the CHK of the just inserted block. Does nothing for fetch requests. > > > > This is potentially useful for filesharing programs, which could communicate > > these blocks to downloaders allowing them to prefetch these blocks before > the > > insertion has completed. > > > > This should encourage filesharing devs to reuse the insertion framework of > the > > node, instead of developing ad-hoc solutions (like freemulet does). > > > > Here follows a sample client/node messages with the patch applied (against > > r19348) > > > > Node -> Client: SimpleProgress > > Node -> Client: Required=6 > > Node -> Client: Failed=0 > > Node -> Client: FatallyFailed=0 > > Node -> Client: Identifier=AdaFN-997468889-598983000-onhvvzvhbozlrgczrhsh > > Node -> Client: Succeeded=5 > > Node -> Client: FinalizedTotal=false > > Node -> Client: > > > URI=CHK at > 0~RgbLmJzOHEXTxRfkm92CEWwZIt7LMEdPblCnWhYpg,dh0stUU9JBAh-qJpy4krFaBlHRuhe8kPr5Q2Mbpc~NM,AAIA--8 > > Node -> Client: Total=6 > > Node -> Client: EndMessage > > > > Node -> Client: SimpleProgress > > Node -> Client: Required=6 > > Node -> Client: Failed=0 > > Node -> Client: FatallyFailed=0 > > Node -> Client: Identifier=AdaFN-997468889-598983000-onhvvzvhbozlrgczrhsh > > Node -> Client: Succeeded=6 > > Node -> Client: FinalizedTotal=false > > Node -> Client: > > > URI=CHK at > lhYtOdRRWori-TaE5s~mB4uDZ5MypJaudIUs5IOI0UI,YT59aVmwkt26LZ4zNU9YVq5cJwo7l8JwAoa6jC6Oy6A,AAIA--8 > > Node -> Client: Total=6 > > Node -> Client: EndMessage > > > > Node -> Client: URIGenerated > > Node -> Client: Identifier=AdaFN-997468889-598983000-onhvvzvhbozlrgczrhsh > > Node -> Client: > > > URI=CHK at > IYLFkexj9iAXb2p2-qSnURQMdEcQ3QGnWgGAzHvtbFA,6wj05kvrZMGtQSsCCtAV3eGB8TGzQ3196la2lSSMvog,AAIC--8 > > Node -> Client: EndMessage > > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -------------- 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/20080416/5da4ea9c/attachment.pgp>
