I was reading the DHT deep dive blog post from the 0.5 IPFS release and had a couple of questions:
In the blog post, Adin writes:
We also search for ourselves in the network (i.e., bucket 255), just in case the network size and distribution are such that the first 15 buckets do not suffice for us to learn about the K peers closest to us.
- What does bucket 255 mean? Does the number 255 have any relevance?
- Does go-ipfs essentially implement 16 buckets (with
Kpeers each) where the first bucket is named the 0 bucket?
As I understand it the look up process for provider records for
X looks as follows:
- create a query queue (), and add
Kclosest peers from our routing table to the query queue
Alphaconcurrent queries asking those peers what are their
Kcloses peers to
Alpha = 10 and
K = 20, at this point we’ve sent 10 queries, each of which will return their
K (20) closest peers to
If each of the 10 initially contacted peers return 20 results the query queue grows from 20 peers up to 200 (if each of the 10 contacted peers returns 20 unique peers).
Is that correct thus far?
Is the query queue implemented using a priority queue where priority is determined by the distance (XOR)?
Assuming that we have 80 peers in the query queue after getting the response from the 10 peers we initially contacted, is this the point where the
Beta parameter (3 for IPFS) is used and basically
Beta peers are queried for the provider value of
(My understanding is loosely based on the lookup algorithm section of the blog post which I’m not sure I fully follow and the docs. It’s also covered nicely by Dennis in the following talk: Optimistic Provide: Optimize IPFS DHT By Dennis Trautwein @ Paris P2P Festival #1 - YouTube