View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007141||GNUnet||DHT service||public||2022-01-03 12:06||2022-01-03 21:13|
|Reporter||schanzen||Assigned To||Christian Grothoff|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|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.