What is the optimal number of nodes in a BitTorrent swarm?
What is the optimal number of nodes in a BitTorrent swarm? I think that there is a mathematical way to express the most efficient number of nodes. To be honest I have a problem with just having an empirical number of X, without some rigor to back it up.
According to this specification the number is 30.
" Implementer's Note : Even 30 peers is plenty , the official client version 3 in fact only actively forms new connections if it has less than 30 peers and will refuse connections if it has 55. This value is important to performance . When a new piece has completed download, HAVE messages (see below) will need to be sent to most active peers. As a result the cost of broadcast traffic grows in direct proportion to the number of peers. Above 25, new peers are highly unlikely to increase download speed. UI designers are strongly advised to make this obscure and hard to change as it is very rare to be useful to do so."
The overhead this quote is referencing is to HAVE messages.
u mean by number of nodes in a swarm. It sounds like you're referring to the total number of participants in a swarm, but your quote is referring to the number of nodes you should connect to. Let's assume the question is the latter.
You also did not specify what performance metric to use. What does efficient mean to you?
If optimal means the lowest number of overhead bytes per payload byte, you want 1 connection (or maybe 0 connections).
Let's assume that you want to maximize your download rate. The answer to this question (how many peers should I connect to to maximize my download rate) is:
The lowest number of peers that will saturate your down-link.
Now, what does this mean? Well, it depends on the swarm, and what capacity other peers have, and it depends on how many distributed copies there are in the swarm.
The other question that also needs to be resolved is, how many peers should you upload to? The answer here is:
The largest number of peers you can divide your upload capacity among, so that they all still reciprocates, or the smallest number that will saturate your down-link
Note that the division does not need to be even, see the bittyrant paper for details.
Now, you need at least that that many connections to unchoke.
The trick in getting good download speed mostly comes down to sending fast enough to peers so that they reciprocate, but preferably not any faster than that. If there's spare upload capacity, it should be used to make another peer reciprocate. Being connected to many peers means that you can find good trading partners a bit faster, and you will be less affected by high churn in swarms.
If you are referring to the optimal number of nodes in the swarm, it is probably somewhere around infinity. Since every leecher is best matched with 1 seeder that has the same upload speed as the leechers download speed.
If you are referring to the optimal number of nodes to connect to as a leecher, this number cannot (or is extremely hard to) be found, because it depends on too much variables. Variables to consider:
So per node there are at least a million possible configurations, then every other node also has these options. So there are 1.000.000^1000 configurations possible for a swarm with 1000 nodes.
When there are a lot of low speed nodes, you will probably want to connect to a lot of nodes.
When there are a lot of high speed nodes, you will probably want to connect to just 1 or 2 nodes.