> > Subject: > Re: [freenet-dev] Splitfiles > From: > "David 'Bombe' Roden" <droden at users.sourceforge.net> > Date: > Thu, 21 Nov 2002 04:13:03 +0100 > To: > devl at freenetproject.org > > >On Wednesday 20 November 2002 23:53, Ian Clarke wrote: > > > >>I was playing with the splitfile stuff, and noticed a few things: >>Right me it is saying Blocks required: 110, Blocks downloaded: 120. >>What is going on? >> >> > >I'm not sure I can do something about that, but... >
I would guess that the number of threads to be used for the splitfile here was 10 or more. The current splitfile downloading does not seem to move on from the downloading mode to the decoding mode until all the active downloading threads have timed-out. This seems to lead to more then the required blocks being downloaded. It isn't necessarily a bad thing to spread blocks around freenet a bit ... it just takes some more waiting time then necessary since. They will get spread already since the request is already out there. It would be nice if these two tasks were handled in parallel (i.e. once the required blocks are downloaded for the current segment, the decoder takes over while the next segment is downloaded) >>Secondly, I wonder whether there could be a cleaner way to keep the user >>up-to-date on progress... Right now, the UI for multi-block downloads >>is pretty confusing (stuff like the "Start Download" page not going away >>after you start the download etc). >> >> > >...I'm currently trying to clean up the splitfile download and insertion >pages - not only are they confusing but also dead ugly. As soon as I've >digged myself through the code for SplitFileRequestContext and >InsertContext expect to see a much nicer UI for those pages (maybe even >embedded in the mainport design). > I would love for the splitfile downloading and decoding to be transparent so that they it could be used in an embedded context (freeweb images). A "details" flag could be made available for people who want to see a GUI and tweak some of the default retrieval parameters. There seems to be some parallel development going on with FEC so make sure that you are not working on something that is going to be obsolete shortly. Mike _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
