[GNUnet-developers] Re: [Help-gnunet] Download never completes, CPU load

[Igor Wronsky]

On Fri, 31 Oct 2003, Kovacs Gabor wrote:

> My downloads usually start in 2-5 minutes and the download is progressing
> well until it reaches 70-80%. (for 3-4Mb files) Then the BPS begin to fall
> and it becomes zero around 97-99%. It seems not to ever be completed.
> (I've waited 3-5 times more than the time required for the 99%)
> Any idea? It's the same if the download is cancelled then restarted.

I've experienced this same problem with some offensive mpegs that
I tried to download for purely scientific purposes. So, first I
thought it was a problem with the files being incomplete
in the network, as 'the incomplete file problem' is typical
to all noncentralized p2p-networks that use file splitting,
but,

the problem is real (developers knowing that part intimately
might pay attention here).

I did the following test with nodes in the current network. On node A,
running 0.6.0a + openssl, I inserted a 5 meg file. On node B running
current CVS and internal crypto, I tried to download the file.
It started agonizingly slowly, then sped up somewhat, but in the end,
for the last 200 kb, not even 8 hours did suffice to download
the rest. Then I tried restart, and I did get a few
additional kilobytes (but not the complete file, atleast
not yet. But it doesn't look promising).

Considering that node A is not very loaded, and node B being
as always, this smells like trouble. Even if the complete file
does eventually arrive after enough restarts, its clear that
either there are bugs in the code or otherwise the timings used
are just not suitable for this kind of application. From
the current behaviour the user will come to the natural
(but wrong) conclusion from p2p experience that the file
is no longer available and stops the download.

Of course this could be explained away by talking about
running out of trust or whatnot. As node B has been online for
ages and helping other nodes to the best of its ability,
without me downloading much of anything, this is still
unacceptable.

The bottom line is that this problem didn't exist in some
previous versions.


Igor