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