I would guess that the number of threads to be used for the splitfile here
Subject:
Re: [freenet-dev] Splitfiles
From:
"David 'Bombe' Roden" <[EMAIL PROTECTED]>
Date:
Thu, 21 Nov 2002 04:13:03 +0100
To:
[EMAIL PROTECTED]
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...
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)
I would love for the splitfile downloading and decoding to be transparent soSecondly, I wonder whether there could be a cleaner way to keep the user...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).
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).
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
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
