arvidn / libtorrent

an efficient feature complete C++ bittorrent implementation

Home Page:http://libtorrent.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Why many connections per ip is bad?

master255 opened this issue · comments

commented

@arvidn

The logic for determining whether connections are to the same peer is more complicated with this enabled, and more likely to fail in some edge cases. It is not recommended to enable this feature.

What's the worst that could happen if I turn this setting on? Isn't it right to check all the ports? What if it is the ip address of the house where 1,000 people live?

As I understand it, downloading a torrent file already happens with this setting turned on?

What's the worst that could happen if I turn this setting on?

that one peer attempts to connect to you so frequently that you fill all your peer slots with the same peer, and then you no longer have a connection to the swarm, but just the attacker.

A slightly less severe consequence is that someone makes a lot of connections to you and receives a disproportional share of your upload bandwidth.

commented

@arvidn Thank you. I need to think about it.

commented

@arvidn But it's not enough not to use it.

Your arguments seem to be outdated.

that one peer attempts to connect to you so frequently that you fill all your peer slots with the same peer, and then you no longer have a connection to the swarm, but just the attacker.

This does not happen in real life. The attacker can not know that I have this setting enabled, besides I may already be connected to other peers and the attacker will not have time to fill all my peer slots so that I can not connect to other peers.

A slightly less severe consequence is that someone makes a lot of connections to you and receives a disproportional share of your upload bandwidth.

Internet speeds are so high these days that it doesn't matter which bandwidth the attacker wants to get.

Perhaps you have a better arguments?

Of course, in order to prevent mass attacks on users in the library, you should leave this setting in false. But in the application, it should be set to true by default.

commented

@arvidn I know a relevant argument. If there is already one connection and data is being transmitted, then even trying to establish a connection to another port will reduce the data rate.
And if there are many such ports, it can significantly reduce the data transfer rate.
It would be nice to make libtorrent ignore other ports if there is already data transfer through one of them.
What do you think?

when you say "port", do you mean connection? Which transfer rate is reduced and why?

commented

@arvidn A port is a port. A connection is a connection. You write a library and ask such strange questions.
The transmission speed will be reduced of the first connection. because of the traffic of the second connection. Because this traffic interferes not only with the client, but also with the server. Therefore, the speed will decrease.

This regularly happens "in the wild" if someone is hosting many torrents with similar/identical content and new peers tend to try to grab multiple ones at once.
Even a single BT client might try to make a connection + use a different port from their end if using TCP for each torrent.
There's no means/method for that single BT client to make only a single connection with a consistent outgoing TCP port number...and be connected to all those torrents on the "seed" at once.

commented

@Seeker2 I am talking about one torrent and one client and many servers on one ip address.

People use bandwith limits for upload and download rates. Libttorrent distributes the available bandwith (data per interval) between all connections. More connections mean smaller packets which leads to decreasing payload/protocol ratios. The client with more connections gets more bandwith (data per interval) than others which is a sort of cheating.

commented

@MassaRoddel We have already discussed this above.

Tit-for-Tat has to consider whether multiple connections are the same peer or that peer will likely be snubbed on most/all of its connections.
Multi-ip downloading also risks duplicate downloading of the same parts and/or confusion over what the total percentage complete is.
Are HAVE messages and percentage complete supposed to be repeated on every duplicate connection?

commented

@Seeker2 It's a lot more complicated than you think. Everything you listed is already taken into account.
Don't write nonsense if you don't know what we' talking about.

Nothing of the sort has been discussed here.