Re: [Help-gnunet] how fast should gnunet be?

[Christian Grothoff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 29 August 2002 05:22 pm, Christian Drechsler wrote:
> hi!
>
> some questions:
>
> a) why doesn't gnunetd give all the matches it finds on the local machine
> - at least when there's nearly no network load at all? when looking for my
> own files it normally takes at least fifteen minutes till they're all
> shown (must be some 500 files i can look for with the same keyword).

GNUnet is not tuned to return results from the local machine since that's not 
what you want most of the time. Also, every node stores at most 1024 results 
for one keyword. GNUnet currently returns multiple results if the load is 
low, but for 500 results, the load would have to be very, very low. Since the 
results returned are random, the next time, there is a fair chance to get 
additional results -- but also to get back the same results again. For 500 
files under the same key, this means that it will take very long to get all 
results. Use more specific keys for the search.

> b) how fast should downloading be? i never managed to download a file at
> all - once i got some 700 bytes (out of about 4 mb), all other attempts (i
> tried ca. 10-15 downloads) never yielded a single byte for hours - some
> were running several days. (well, ok, there was this "0 connected
> hosts"-stuff (see below), so maybe there was no host available half of the
> time. X-) )

Downloading can take forever -- if the node that has the data is offline or at 
least not connected to the group of nodes that you are in. There is currently 
no feedback that would tell you that this is probably the case. If the node 
gets back online, your download would continue as usual. 
The 0 connected problem has been reported but could not be reproduced, 
especially not when we tried to debug it. Any information on how to reliably 
(and quickly if possible) reproduce it will be appreciated.

> c) i have an adsl line from the german telekom, which means 768kbit
> downstream, 128kbit upstream. the INDIRECTION_TABLE value was much too
> low, it seems, with 8092. now it's got the value of 65536 - and is already
> full again after gnunetd running for 1300s.

It is not the end of the world if you have a collision, this just happens. 
This does not mean that somebody's download fails, it just means that your 
node can not keep track of more queries (which is usually fine). You can 
increase the number as high as you want (depending on how much memory you 
have, of course). But note that by the birthday paradox, the chance of having 
a collision is 50% for sqrt{size} queries. But again, a collision is not 
really a problem.

> d) it happens quite often that after a day or so there are zero connected
> hosts. why? (i didn't test with the bigger indirection table, yet - could
> that have sth to do with it?)

Good question. And no, the indirection table size can not have anything to do 
with it.

> e) sometimes, after adsl reconnection (happens at least once/24h), gnunetd
> tries to determine the IP too early and dies:
>
> from logs:
> Aug 25 14:35:41 Could not obtain IP for interface ppp0 with ioctl
> Aug 25 14:35:41 FATAL: my own IP address is blacklisted in my local
> configuration!
>
> from /var/log/messages:
> Aug 25 14:35:41 zottel pppoe[24208]: PPP session is 6728
> Aug 25 14:35:42 zottel pppd[24207]: local  IP address xxx.xxx.xxx.xxx
> Aug 25 14:35:42 zottel pppd[24207]: remote IP address xxx.xxx.xxx.xxx

Hmm. We may want to change the "errexit" into a "WARNING" or something. A 
workaround would be not to blacklist any IPs.

> f) there are new WARNINGs in the logs i never saw before:
>
> Aug 30 00:10:13 WARNING: Invalid sequence number 2157 < 2191, dropping rest
> of packet
>
> is that because some 0.4.9 stuff is tested, or what's that?

No, you will not be able to connect to 0.4.9 nodes. This warning occurs if a 
packet arrives out-of-order, in particular, if MAX_PACKED_ID_RECEIVED - 32 > 
PACKET_ID. So if packet 40 arrives before packet 8, you will get this warning 
and packet 8 will be dropped (no harm done, just 1k bandwidth lost). The 
reason is, that we have to protect against replay attacks, but we can't/don't 
want to waste memory on keeping track of more than the last 32 packets.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9bt5o9tNtMeXQLkIRAh1uAJ4vWWcf8nqb2aWvczGVXcEhVJBQdwCfVh9H
G/P3RgfKDtDSwRAMZ1GaTOQ=
=SxoP
-----END PGP SIGNATURE-----