1

I m trying to implement a DHT using Kademlia paper as a way of understanding better how these systems work.

I have read some other articles that referes to this way of implementing a distributed hash table but there is something I can't wrap my head around. In a p2p exchange files network, key ids could be implemented as digest of filename for consistency throught search mecanism.

But what about node id itself ?

Should I, for example, take the digest of "WAN-IP:PORT" combination or simply generate a completly random id from scratch ?

In the second case scenario, there is alway a risk that two nodes generate the same id. But using my WAN-IP:PORT I rely on the fact that my client is running a node behind a WAN-IP that should never change.

How should it come from the network itself ? I mean, on first contact, the peer work some magic and give the new node an id ?

I would appreciate some inputs on how to implement Kademlia node id generation.

SunPaz
  • 145
  • 7
  • Does this answer your question? [In Kademlia, why is it recommended to have 160-bit node IDs and keys and not 128-bit?](https://stackoverflow.com/questions/56431524/in-kademlia-why-is-it-recommended-to-have-160-bit-node-ids-and-keys-and-not-128) – the8472 Aug 24 '20 at 18:07
  • @the8472 No, but thanks, I answered myself, just can't flag it. – SunPaz Sep 16 '20 at 19:36

1 Answers1

1

As stated in Kademlia paper, "Node IDs are currently just random 160-bit identifiers, though they could equally be constructed as in Chords".

Chords uses the SHA-1 digest of a node IP.

SunPaz
  • 145
  • 7