Last Active: Dec 06, 2019
Threads: 186
Posts: 1,866
Reputation:
32
Feb 21, 2014, 04:09 am
(This post was last modified: Feb 21, 2014, 04:33 am by joew771. Edited 1 time in total.)
The way I understand it is that utorrent, and most other torrent clients, create a random node ID upon connection, not based on geography or IP address, but just a random number. So a node in Sweden and a node in the US may have less 'distance' than 2 nodes that are both located in the US for example, depending on what random ID's were created.
This 'distance' is computed and used to determine what node ID's are stored in the routing table of the client. And then the client attempts to connect to the 'closest' nodes first, which after connecting will give more nodes to add to the routing table, and will then attempt to connect to the closest of those, etc. until it has reached the maximum limit of connections.
Because you may not connect to every single node that is added to your routing table, you may end up connecting to nodes that are 'far away' from your node.
So when the client reaches it's max connections, it won't connect to anyone else, no matter how close their node ID is to yours and new connections will be blocked. But with the new system, if a node appears that is closer to yours, it will kick off a node that is further away and connect to the closer one.
So your connections won't be 'locked up' by malicious users who are further away, because they will at some point be booted off by someone with a closer node ID. It won't guarantee that a closer node isn't malicious as well, but at least it swaps the users out more often than just keeping the first come first served connections that may stay connected and not contribute to the swarm.
EDIT:
(Feb 21, 2014, 01:59 am)kjf Wrote: Of course, on an individual basis, there will be circumstances where a fast peer with high availability will get booted for a slow peer with next to nothing simply because the newcomer's network address is closer to home. I find it hard to believe that wasn't taken into account, but I see no mention of it.
I also don't see how they will prevent that. Maybe through monitoring the connection speeds and NOT booting someone with a faster transfer rate but further away in favour of a closer but slower rate? No idea.
Last Active: Apr 13, 2015
Threads: 62
Posts: 2,121
Reputation:
5
(Feb 21, 2014, 02:46 am)NIK Wrote: (Feb 21, 2014, 01:59 am)kjf Wrote: Of course, on an individual basis, there will be circumstances where a fast peer with high availability will get booted for a slow peer with next to nothing simply because the newcomer's network address is closer to home. I find it hard to believe that wasn't taken into account, but I see no mention of it.
That's the bit that I hadn't worked out. And, like you, I also find it hard to believe (so I suspect that I've missed something because Arvid Norberg is a genuinely smart cookie).
fyi, I've worked it out now. And we did miss something that Norberg didn't, which is why he didn't mention it--because in spite of what we think it's actually irrelevant.
We were right that the implications are that sometimes your client will disconnect "a fast peer with high availability" but from the global perspective it doesn't matter. The "fast peer with high availability" isn't lost to the swarm, they're merely transferred from one peer to another. ie. half the time you will be on the losing side of the deal but half the time you will be on the winning side. Across multiple torrents, you will come out even. And, since all swarms will run slightly more efficiently, you will actually end up slightly better off than even.
(Feb 21, 2014, 04:09 am)joew771 Wrote: The way I understand it is...
You've described the way DHT works, not BitTorrent. They're quite different.
BitTorrent doesn't consider distance of any kind in determining which peers to connect to. It freely accepts new connections up to the connections-per-torrent (or global connections) limit and only disconnects when "keep alives" fail. A satiated peer doesn't accept new connections, period.
[What may occur to you from that is that the torrent clients you are connected to on the BitTorrent network might be different to the ones you're connected to on the DHT network. That is correct.]
Last Active: Feb 09, 2015
Threads: 18
Posts: 2,036
Reputation:
13
(Apr 19, 2014, 08:25 am)NIK Wrote: fyi, I've worked it out now. And we did miss something that Norberg didn't, which is why he didn't mention it--because in spite of what we think it's actually irrelevant.
We were right that the implications are that sometimes your client will disconnect "a fast peer with high availability" but from the global perspective it doesn't matter. The "fast peer with high availability" isn't lost to the swarm, they're merely transferred from one peer to another. ie. half the time you will be on the losing side of the deal but half the time you will be on the winning side. Across multiple torrents, you will come out even. And, since all swarms will run slightly more efficiently, you will actually end up slightly better off than even.
Thanks for the update. I definitely wasn't thinking globally. I was just being selfish and thinking about immediate personal loss. 
Last Active: Jun 05, 2017
Threads: 308
Posts: 515
Reputation:
8
This article convinced me to update to 3.4 from 2.2.
The new system reduces the overhead as you'll be connecting to fewer hop peers,
thus allowing more payload especially for slow peers.
(Feb 21, 2014, 01:59 am)kjf Wrote: Of course, on an individual basis, there will be circumstances where a fast peer with high availability will get booted for a slow peer with next to nothing simply because the newcomer's network address is closer to home.
How bout increasing the maximum number of connections per torrent so no peer is wasted.
Last Active: Feb 09, 2015
Threads: 18
Posts: 2,036
Reputation:
13
(Apr 19, 2014, 13:04 pm)lebeque Wrote: How bout increasing the maximum number of connections per torrent so no peer is wasted.
There are diminishing returns here. Every peer you connect to uses a certain amount of your bandwidth for protocol even if you are not exchanging pieces with them. Usually your client calculates an optimal number based on available bandwidth. There is probably little to gain from increasing this.
If you find yourself rarely using all your available bandwidth, you can try increasing this number. The corollary here is that if the majority of the rest of the swarm is maxed out, they are just going to refuse your connection attempts.
Last Active: Apr 13, 2015
Threads: 62
Posts: 2,121
Reputation:
5
(Apr 19, 2014, 13:04 pm)lebeque Wrote: This article convinced me to update to 3.4 from 2.2.
Oh, that's a pity.
Although this is a genuine step forward it is a very small step, and the step from 2.x to 3.x was a giant step backwards. You're now in a world of bloated bug-ridden code.
Do yourself a favour and revert back to 2.2 (or, better yet, 2.0.4) sooner rather than later.
(Apr 19, 2014, 13:04 pm)lebeque Wrote: The new system reduces the overhead as you'll be connecting to fewer hop peers,
thus allowing more payload especially for slow peers.
No. There isn't any such thing as a "hop peer" that was merely an explanation of what happens under the traditional model if you try to connect to a peer who already has more connections than they can handle. It is an exception rather than rule. ie. most of the time there is no hopping.
And in any case, neither the tradition model nor this modification has anything to do with "increasing payload" for either slow peers or any peers.
[As for "increasing the maximum number of connections", kjf is right--it mostly does more harm than good]
Last Active: Jun 05, 2017
Threads: 308
Posts: 515
Reputation:
8
(Apr 19, 2014, 19:25 pm)NIK Wrote: Do yourself a favour and revert back to 2.2 (or, better yet, 2.0.4) sooner rather than later.
I still use 2.2.1 when uploading, I'm trying 3.4.1 for downloading.
You're right about the hop, i thought it's something related to overhead.
So this means nothing so much on this 3.4.1, will now go back to 2.2.1 
|
