gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Query TTL question


From: Christian Grothoff
Subject: Re: [GNUnet-developers] Query TTL question
Date: Thu, 22 Jan 2004 14:45:46 -0500
User-agent: KMail/1.4.3

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

On Thursday 22 January 2004 03:38 am, Hendrik Pagenhardt wrote:
> Hello,
>
> I noticed quite high numbers in the statistics of my gnunetd regarding
> p2p namespace queries:
>
> <DATA>
>
> So that means my node receives about 184 namespace queries per second.
> Compared to the other query numbers this appears very high. Is this
> normal behavior? And if yes, why are so many NS queries floating the
> network?

There's a bug, Igor has already (in private mail) reported the same behavior.

> I looked through the sources then and found the following in handler.c:
>
>   if (ttl < 0) {
>     ttl = ttl - 2*TTL_DECREMENT - randomi(TTL_DECREMENT);
>     if (ttl > 0)
>       return OK; /* just abort */
>   } else
>     ttl = ttl - 2*TTL_DECREMENT - randomi(TTL_DECREMENT);
>
> This is part of "handleNSQUERY" and "handleQUERY" and is executed before
> the query is evaluated. When I read it correctly, it decrements the TTL
> by between twice and three times TTL_DECREMENT. When the TTL was
> negative before, it is tested after the decrement to be positive, and if
> true handling the query is aborted. In effect this means that when an
> underflow of the TTL occurs, it is dropped? And only then? Shouldn't it
> be dropped when the TTL becomes negative with a certain probability?

No, drops are relative to other TTLs in the system and happen in routing.c, 
they don't probabilistically depend on the absolute TTL value but only on the 
TTL relative to other TTLs.  The underflow handling is just there to avoid an 
attack where I send  MIN_INT, you check that it is 'not unreasonably large', 
then decrement it (get a very large TTL due to underflow) and then route that 
query 'indefinitely'.  The underflow should never happen in 'normal' 
operation.

> And there is a difference between "handleNSQUERY" and "handleQUERY":
>
>   /* adjust TTL */
>   if ( (ttl > 0) &&
>        (ttl > (int)(prio+3)*TTL_DECREMENT) )
>     ttl = (int) (prio+3)*TTL_DECREMENT; /* bound! */
>
> This is only used in "handleQUERY", but I think it should be done also
> for namespace queries...

Right, the handling of the two should always be symmetric, and while this one 
should not result in the 100 NS-query-per-second problem (Igor's 
investigation so far seems to point at routing.c) it should be fixed also.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFAEChq9tNtMeXQLkIRAuMcAJ9jG0eKNaZ7xk+m3angLFz5V6PqZQCdFdDC
QjKh//mzAV/XoL8Aw6F4Xrs=
=hMEx
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]