On Thu, Mar 13, 2003 at 01:59:51PM -0500, Dan Merillat wrote: > There's a few splitfiles out there (*cough*movie central*cough*) That > are barely retrievable because of impatience. > > The first segment returns fine, but each segment after that has higher > and higher loss rate. In fact, this is the exact problem we had with > splitfiles when they were retrieved linearly (first blocks were always > found, latter blocks were gone) > > The problem is REALLY aggrivated when people retry over and over... they > heal segment 1 a lot, so it has close to 100% retrievability, but > segment2, 3, 4 lose more and more blocks. > > "obviously", we should retrieve the segments in random order. That has > the obvious problem that we can't send the file until the download is > complete, anyway.
The problem with that is that if we are sending the data to the browser, it should be possible to send it a segment at a time. > > So, let's step back a second on this. Browser timeout is killer on > large files already, that download session going for possibly hours > without getting a single byte. So, why not spool the file to local > holding and initiate the download to the browser once the whole thing > is there. In other words, implement the background download manager thing ian has been suggesting (and oskar before that)? Good idea. Whether we save direct to the final filename or save to a buffer area and then let the user grab the file all at once is open to question; probably we should implement some way of doing either or both. > > I'd prefer this solution, actually... this way I can simply wget the > resulting file to wherever I want it (or copy the segments from > store/tmp) and be able to check the progress from anywhere (by knowing > the splitfile ID URL) > > --Dan -- Matthew Toseland toad at amphibian.dyndns.org/amphibian at users.sourceforge.net Full time freenet hacker. http://freenetproject.org/ Freenet Distribution Node (temporary) at http://80-192-4-36.cable.ubr09.na.blueyonder.co.uk:8889/069-bfPzGwU/ ICTHUS. -------------- 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/20030313/e999676d/attachment.pgp>
