There is no real reason why we can't allow the client access to the block URIs, if he sets a sufficiently high feedback reporting level.
Hence, when you do an insert, it will tell you when it starts inserting each block, what that block's key is. Likewise on a request, if it fails, it could tell you which segment failed, and which keys from that segment were successfully fetched (the rest failed). Because of the way FEC works, it will then be sufficient to reinsert any of the remaining keys in that segment; in practice we would reinsert all of the remaining keys in the segment for reliability reasons. So: Fetch knoppix_4.0.1.dvd.iso Segment size = 128 data blocks, 64 check blocks. Segments 1-27,29-451 succeeded. Segment 28 failed: 192 blocks in segment. 128 data blocks in segment; need 128 blocks. Fetched 117 blocks. <list of 117 fetched blocks> Need 11 of the remainder: <list of 75 failed blocks> The easiest way to implement the insert end would be simply for the client to reinsert the entire segment. This would require no node support apart from the above information; the client could simply chop that part of the data, and insert it as a splitfile. A more complex option would be to reinsert specified blocks only from a splitfile. I do not regard that as a priority. But providing enough information to do the above is easy enough. I still don't agree with you on the need for insert on demand btw; a working freenet would have massive resources, and work far better for less-popular files than most P2Ps, due to having more places to download them from. The problem is that all production freenet's so far have had serious load-versus-routing problems. Hopefully 0.7's algorithms will do better, since they a) Are based on tried and tested solutions, and b) Propagate overload back to the source (the client node). -- 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/tech/attachments/20051206/7a15feb1/attachment.pgp>
