Make peers cooperate with other leachers more

[zavalyshyn]

We always have one seeder in the beginning. This seeder will be a peer on a server's side. We want to minimize interaction with this seeder (at least after some point) and communicate with other downloading peers more.

Possible ideas: limit the number of concurrent connections on a server's peer side, e.g. to 2. In this case only 2 peers will be downloading from server directly, rest of the peers will have to download from neighbor nodes.

[zavalyshyn]

We should invent an algorithm to identify those 2 peers that will have direct connection to the server. Probably it should be those peers that are closer to it. We can try to identify such peers by checking the link quality to the gateway. If this link's quality is higher than particular value we allow connection, if it's lower - deny.

[emmdim]

Are you sure that their proximity to the server is a good metric to choose? I mean ideally a node should choose a neihgbor that is close to him and that has the most chunks are still missing. No?

[zavalyshyn]

yep. but we're talking about the beginning of download, when nodes don't have anything yet. The only source of a file is a seeder on a server's side. In this case all the nodes will start downloading directly from the server and only after some time they will start exchanging pieces between each other.

So if we want to stimulate the pieces exchange between the nodes instead of direct download from the server we could allow direct download only for particular peers. Others will just download from them.

I'm still thinking of a best way to do it. Your thoughts would be welcome

[emmdim]

I think as I said in some discussion, that the system should be devised in a way that the nodes after some point will prefer local nodes. Using one metric from the beginning to the end, it will be natural that for an initial period all the nodes in the beginning will download only from the server. Then, the nodes should start preferring more local options. This a tricky point. And it depends if we want to have the most efficient solution or the most distributed one. So we should decide that first.

[emmdim]

In general the metric can contain information about connectivity (like the batman-adv metric), delay (some iperf measurement), maybe network congestion(more difficult), maybe availability of missing chunks(that should already be a part of libtorrent i guess) and ofcourse proximity.

[kendanniswara]

Other than priorities by the different metrics, if we really want to drop the connection to the seeder/server to download only between peers, we need also consider that all the pieces is already in the network. If not then download will not finished.

Our current consideration is limitation for each node is downloading from whom. For example in below image, node 11 & 12 will prefer to download from server because of good PathQuality, node 13 & 14 will never ask connection to the server because the quality is very low (not preferred), but ask 11 & 12 respectively.