[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gnunet] A couple problems with gnunet 0.4.2 - Also compile pro
From: |
Igor Wronsky |
Subject: |
Re: [Help-gnunet] A couple problems with gnunet 0.4.2 - Also compile problems in 0.4.3 |
Date: |
Fri, 2 Aug 2002 18:34:15 +0300 (EEST) |
On 29 Jul 2002, Josh Grebe wrote:
> #3QUERY received: 113621090 send: 215408493
> #CONTENT received: 14746 send: 24878
> #NOISE received: 2740252k send: 1750544k
> #octets received: 443650k send: 536897k
> #QUERY received: 324798 send: 0
> #CONTENT received: 0 send: 2017
> I am getting some search results, not having a lot of luck trying to
> download files though.
Some points are in order so that you won't feel ignored. ;) First,
those are not small figures. 324798 queries signifies you tried
to download something pretty big, or you were pretty persistent
with smaller stuff. Though I haven't noticed an upper limit on
filesize in gnunets capability of transferring files, I wouldn't
personally attempt download anything over 10 megs at this point.
Mainly, the large content I've been able to found is not interesting
enough to download at the speeds my node can achieve. Note that
the competitors (the F-word, some people don't like it mentioned
here...) on the anonymous front have had problems with big
stuff as well. Compared to that mess, gnunet has been coming
up quite nicely, in my opinion.
Second, even if you didn't get files satisfactorily, your node
was not useless by any means: the number of queries and content
received/sent tells that your node has delivered stuff
around quite nicely.
Only thing that seems weird to me is that your #NOISE
is higher than #octets. I've never seen that personally. It
might signify a problem. Do you have any idea (e.g. from
the logs, or an udp packet monitor) where thats coming from?
ps. as the above implies, personally I've been able to download
files just fine recently, only slow. One of the main download-related
problem to fix now is to create some to measure the file
availability on the net, that is, provide user with knowledge
that can help to decide if a download should be attempted at all.
The current way gnunetd works makes it possible for search to
return results of files that are not available fully in the
network anymore (and it might be overly optimistic to
suppose they'd come back). We've been scheming some ideas with
Christian but the issue is not solved. Suggestions are
welcome.
- Re: [Help-gnunet] A couple problems with gnunet 0.4.2 - Also compile problems in 0.4.3,
Igor Wronsky <=