I just noticed that one that one of my splitfile downloads was stuck (no
data is downloaded and each try to fetch the download status using the
browser causes another thread to be stuck), the cause seems to be a
deadlock. The last thing the wab interface said was 'Decoding FEC block,
please be
On Thu, 06 Mar 2003, Matthew Toseland wrote:
> the MIME handling code. For downloads, we stream the buckets straight
> out, the worst case for a segment is we got all 64 check blocks, and 64
> of the data blocks, we have to reconstruct the other 64 data blocks, so
> we are using 150% of the
On Thu, 06 Mar 2003, Matthew Toseland wrote:
the MIME handling code. For downloads, we stream the buckets straight
out, the worst case for a segment is we got all 64 check blocks, and 64
of the data blocks, we have to reconstruct the other 64 data blocks, so
we are using 150% of the original
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 05 March 2003 10:17 pm, Greg Wooledge wrote:
> Scott Young (scottyoung at adelphia.net) wrote:
> > Also, I have a lot of partitions. Freenet is installed on my F drive,
> > the temp directory is on my C drive, and I was saving the movie
Quoting Scott Young :
> I was thinking it would be better to do what other programs do for
> partial downloads: .dat files. An in-place reconstruction of the file
> could take place after enough data for each segment is downloaded. If
> the user can tell Freenet where they want to store the
On Wed, Mar 05, 2003 at 10:17:25PM -0500, Greg Wooledge spake thusly:
> We have the same problem here in Unix-land. Every browser I've got
> wants to save files into the /tmp directory before copying them to
> their final destination. I don't understand why.
This bugged me for a few days. Start
On Wed, Mar 05, 2003 at 08:39:37PM -0800, Ian Clarke wrote:
> Yes they should, good observation. We do, however, need to be careful
> about memory usage (and, to a lesser extent, disk usage) when sewing the
> segments back together (it would be tempting to load them all into RAM
> at once and
On Wed, 2003-03-05 at 23:43, Frank v Waveren wrote:
> On Wed, Mar 05, 2003 at 08:39:37PM -0800, Ian Clarke wrote:
> > Yes they should, good observation. We do, however, need to be careful
> > about memory usage (and, to a lesser extent, disk usage) when sewing the
> > segments back together (it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 05 March 2003 10:17 pm, Greg Wooledge wrote:
Scott Young ([EMAIL PROTECTED]) wrote:
Also, I have a lot of partitions. Freenet is installed on my F drive,
the temp directory is on my C drive, and I was saving the movie to my H
On Wed, Mar 05, 2003 at 10:17:25PM -0500, Greg Wooledge spake thusly:
We have the same problem here in Unix-land. Every browser I've got
wants to save files into the /tmp directory before copying them to
their final destination. I don't understand why.
This bugged me for a few days. Start a
On Wed, 2003-03-05 at 23:43, Frank v Waveren wrote:
On Wed, Mar 05, 2003 at 08:39:37PM -0800, Ian Clarke wrote:
Yes they should, good observation. We do, however, need to be careful
about memory usage (and, to a lesser extent, disk usage) when sewing the
segments back together (it would be
Quoting Scott Young [EMAIL PROTECTED]:
I was thinking it would be better to do what other programs do for
partial downloads: .dat files. An in-place reconstruction of the file
could take place after enough data for each segment is downloaded. If
the user can tell Freenet where they want to
The idea is very good otherwise. And if some way to get around baby-sitting a
download could be had...
FYI: I'm getting throughputs of 10-15K on files of ~700M. I'm impressed.
Only for download :)
-todd
--
Matthew Toseland
[EMAIL PROTECTED]/[EMAIL PROTECTED]
Full time freenet hacker.
Scott Young (scottyoung at adelphia.net) wrote:
> Also, I have a lot of partitions. Freenet is installed on my F drive,
> the temp directory is on my C drive, and I was saving the movie to my H
> drive. One thing I noticed was that when the download was done, Mozilla
> was saving a copy of the
> First of all, shouldn't segments be downloaded randomly like each of the
> blocks are? Large downloads could get too unreliable after a few
> segments if a lot of people stop downloading part way.
Yes they should, good observation. We do, however, need to be careful
about memory usage (and,
I just downloaded LOTR from Freenet, and I've noticed some minor
problems with downloading large SplitFiles:
First of all, shouldn't segments be downloaded randomly like each of the
blocks are? Large downloads could get too unreliable after a few
segments if a lot of people stop downloading part
I just downloaded LOTR from Freenet, and I've noticed some minor
problems with downloading large SplitFiles:
First of all, shouldn't segments be downloaded randomly like each of the
blocks are? Large downloads could get too unreliable after a few
segments if a lot of people stop downloading part
On Wed, Mar 05, 2003 at 09:50:45AM -0500, Scott Young wrote:
I just downloaded from Freenet, and I've noticed some minor
problems with downloading large SplitFiles:
I didn't hear that. I wouldn't want to expose myself to liability for
conspiracy to commit copyright violation, please avoid
Scott Young ([EMAIL PROTECTED]) wrote:
Also, I have a lot of partitions. Freenet is installed on my F drive,
the temp directory is on my C drive, and I was saving the movie to my H
drive. One thing I noticed was that when the download was done, Mozilla
was saving a copy of the file to the C
First of all, shouldn't segments be downloaded randomly like each of the
blocks are? Large downloads could get too unreliable after a few
segments if a lot of people stop downloading part way.
Yes they should, good observation. We do, however, need to be careful
about memory usage (and, to a
On Wed, Mar 05, 2003 at 08:39:37PM -0800, Ian Clarke wrote:
Yes they should, good observation. We do, however, need to be careful
about memory usage (and, to a lesser extent, disk usage) when sewing the
segments back together (it would be tempting to load them all into RAM
at once and
21 matches
Mail list logo
