View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007141||GNUnet||DHT service||public||2022-01-03 12:06||2022-02-26 23:10|
|Reporter||schanzen||Assigned To||Christian Grothoff|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||0.16.0||Fixed in Version||0.16.0|
|Summary||0007141: Bucket lists are not ordered?|
|Description||It seems like the bucket lists are not ordered.|
New connections are always added at the tail https://git.gnunet.org/gnunet.git/tree/src/dht/gnunet-service-dht_neighbours.c?id=f72a57c08e2f3d4c55fd0a700b48138fdfe8df5d#n767
I am currently unsure if this is good. It means that if we establish a lot of connections (new peers) we may never use them for routing because of "bucket_size".
This in turn may eventually lead to a disconnect by transport because of idleness.
Should the eviction/ordering strategy be improved?
Add new connections on head?
Occasionally include peers beyond bucket_size?
Order peers in bucket by XOR closeness?
Well, there are generally good reasons (Sybil attacks, etc.) to strongly prefer long-lived connections, which is what the current policy does.
With TNG, we _may_ eventually modify this to also incorporate transport performance considerations in combination with lifetime, but this must be done very, very carefully.
For now, I believe the specific choice for the LSD should either be "oldest connections available" or deliberately not specified.
||Fix committed to master branch.|
||Longest-lived preferred is implemented in the C code and now clearly documented as required in LSD 0004 as per e676368..c18963a. Resolving the bug.|
|2022-01-03 12:06||schanzen||New Issue|
|2022-01-03 12:06||schanzen||Status||new => assigned|
|2022-01-03 12:06||schanzen||Assigned To||=> Christian Grothoff|
|2022-01-03 14:39||Christian Grothoff||Note Added: 0018623|
|2022-01-03 21:13||schanzen||Tag Attached: lsd0004|
|2022-02-23 23:19||Christian Grothoff||Changeset attached||=> lsd0004 master c18963a9|
|2022-02-23 23:19||Christian Grothoff||Note Added: 0018714|
|2022-02-23 23:19||Christian Grothoff||Status||assigned => resolved|
|2022-02-23 23:19||Christian Grothoff||Resolution||open => fixed|
|2022-02-23 23:20||Christian Grothoff||Fixed in Version||=> 0.16.0|
|2022-02-23 23:20||Christian Grothoff||Note Added: 0018715|
|2022-02-23 23:20||Christian Grothoff||Target Version||=> 0.16.0|
|2022-02-26 23:10||schanzen||Note Added: 0018722|
|2022-02-26 23:10||schanzen||Status||resolved => closed|