Re: [Help-gnunet] A couple problems with gnunet 0.4.2 - Also compile problems in 0.4.3

[Igor Wronsky]

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.