I am working on a p2p network, where latency is priority, so suppose i have to go from A to C, A and C are nearby in term of latency but far in terms of XOR, in order to find C, i have to route by B, which is far from A in terms of latency, so i am thinking will it be a good idea to keep track of closer peer(latency) in the routing table rather than latest available, so for this case if i use latency there is a higher chance that instead of B i will find a peer which has lower latency for routing.
Very good way of thinking, lack of latency awareness is one of the main drawbacks in DHTs.
However, I would recommend to maintain in a separate data structure the latency peers and their information, and whenever you have a non-full bucket to use it.
If you replace latest available with latency, you will recover much slower from user churns, and you will not be resilient to them. Also, you could get isolated more easily.
Hope it helps
but as far as i understand the code we are using the oldest available instead of latest available, is that correct?, here we are rejecting any new node that isnt preasent in bucket if its full
if we use latency along with proper timeout, i think we can also recover from unexpected connection break without TCP FIN
Sorry, I don’t know if I explained myself well. Kademlia’s original implementation tries to replace the Latest Available peer by the newly discovered. It PINGs the Latest peer, and if it does not respond, it exchanges by the newly discovered node.
So, when would you like to use the latency?
after pinging the latest peer, the default implementation is to add the latest peer in the front of bucket, what i want to do it store the peer in ascending order by latency in the bucket
Okay, now I understand it. In P2P networks, usually the peers that have been connected for a long time are more likely to remain connected for a longer time, than other peers that have been connected for a short-time. That is one of the main reasons for prioritizing old peers. So, if you apply your latency optimization, you will lose this property.
It will probably still work well, but the resiliency will decrease and the buckets-maintenance work will increase. Have you thought of any other way of applying latency metrics, which do not involve the bucket order?
so basically we can have 2 types of peers,
- Old and resilient peer
- Low latency Peers
what about creating another bucket for each entry in kadmelia like u said, and always prioritising latency bucket for fetching
Mmm that’s quite a good idea! So, for querying use the latency peers, and for replacing the oldness.
I looks very promising, but I would need to test it, in order to tell you if it does not lose DHTs properties.