A method to connect peers according to their bandwidth capacity.

[Martin Levac]

Greetings,

I don't know exactly how to explain it but I'll try anyways. I'd like it if uTorrent had a method to determine bandwidth capacity (or limits if peers set them) so that peers could connect to other peers with similar bandwidth capacity. I think it would allow fast peers to get better performance from torrents since they'd connect to other fast peers and so forth.

ML

[Firon]

Nope. Not possible.

The only thing you can do is what the BitTorrent protocol does right now: look for new peers to upload to with optimistic unchoke and see if it's a better peer to upload to (because it gives you more bandwidth), and disconnect idle peers to try to find new ones.

[Ultima]

You can't measure bandwidth capacity in BitTorrent.

[Martin Levac]

BitTorrent uses the TCP protocol and if I remember correctly, the TCP protocol has a built in method to determine bandwidth capacity of any connection on the fly. BitTorrent goes one step further, it lets the user determine upload bandwidth right from the start. Utorrent has both upload and download bandwidth control. Why not use these parameters to connect peers who have similar bandwidth capacity?

ML

[DreadWingKnight]

This will fuck with the peer connection metrics built into bittorrent causing peer clustering, also fucking over the connections between clusters.

There's a reason the trackers give out random peers instead of localized or otherwise high bandwidth peers. What you're proposing basically completely screws over peers with lower-capacity connections.

[Switeck]

"similar bandwidth capacity" on BitTorrent is meaningless, beyond broadband connections versis dial-up...and sometimes even then!

It's all about how the individual BitTorrent clients are configured.

Lots of BitComet clients are on very fast connections, but they have so MANY upload slots enabled that their upload speed PER slot is less than 0.3 KB/sec. There's even a few µTorrent clients doing the same thing.

The BitTorrent protocol already looks for the fastest uploader to you and tries to upload back to it so it will continue uploading to you. It also has 1 random upload to seek out other fast uploaders...and just to share a little overall regardless of how fast the other end is.

[tumu]

Like Switeck said, if everyone would set their upload speed and slots properly, swarm speeds would improve. Because people are greedy, this won't happen and everyone suffers.

[Martin Levac]

DreadWingKight, there's already peer clustering in BT and it is caused by the BT protocol. What is the reason the trackers give random peers? Low bandwidth peers are already fucked by nature, they can't get more than their lines can take. The same thing happens when a peer sets a low upload limit.

Switeck, is tit-for-tat meaningless as well? The BT protocol doesn't look for the fastest connection, it only keeps it when it finds one through chance. All connections are randomly created between peers, then the fastest ones are kept for as long as there's new data to exchange. See what DreadWingKnight said about peer clustering.

Tumu, do you mean to say that those who set their upload to 4kB/s would get more? That's not how BT works. The less you give, the less you get. The reverse is true but it's all controlled by chance, not by explicit parameters determined by the user.

ML

[DreadWingKnight]

DreadWingKight, there's already peer clustering in BT and it is caused by the BT protocol.

Give me proof please.

What is the reason the trackers give random peers?

The reason that trackers give random rather than regionalized or bandwidth-linked peers is to keep bandwidth and piece availability as high and as spread out as possible.

[bleh]

yes, the whole point with the randomness implemented in the bittorrent protocol, is to ensure that everyone gets a fair share, and that the file gets as distributed as possible, hence everyone has to chip in a bit of their bandwidth to help the swarm as a whole.

[tumu]

Martin, try reading my post again. There is no chance involved in setting appropriate upload speed and slot count for a connection. In addition, running too many torrents on limited upload hurts swarm speed in each torrent.

[Martin Levac]

DreadWingKnight. Peer clustering happens normally when reliable peers connect to each other. The BT protocol favors connections between reliable peers once they are found to be reliable and tries to disconnect unreliable peers, inactive connections and snubs peers that have no new data to trade. The BT protocol does not try to connect reliable peers explicitly, that happens by chance. Now give me proof that what I suggest will cause peer clustering that will hurt torrent performance. I think that it will still cause peer clustering but it will improve torrent performance since peers with similar bandwidth capacity will favor connections to each other right from the start. Faster peers will become seeds quicker which can only benefit the swarm. Perhaps you don't want to see so many leeches? That happens already whether we want it or not and it will happen again.

Tumu. Running too many torrents is irrelevant since the bandwidth capacity of a particular peer is determined from each individual connection once the connection is made. Setting appropriate upload speed and slot count is irrelevant when determining connections between peers, that is done by chance. Keeping those connections is entirely different since it is done after the connection is established and reliability of those connections comes into play. A peer with low upload capacity is not considered reliable so it gets disconnected often. A peer with high upload capacity is considered reliable so it maintains its connections to other peers for as long as there's new data to trade. The determination of reliability is only done once the connection is established. All connections are created randomly.

Bleh. That's exactly how BT works. That's also the reason why there are no explicit parameters that determine connection between peers of similar bandwidth capacity. Furthermore, because of the method to determine reliable connections between peers after the connection has been established, reliable peers get locked with each other creating peer clusters unless there's no new data to trade. Even then the connection is maintained because it is still deemed to be reliable and when new data becomes available, data trading between those two peers is favored over other unknown reliability peers.

The determination of reliability is done only from the connections one peer has to other peers and only for that one peer. This information is not traded throughout the swarm. Otherwise the BT procotol would not need to optimistically unchoke random peers just to see if the connection to that peer was reliable.

ML

[DreadWingKnight]

Peer clustering happens normally when reliable peers connect to each other. The BT protocol favors connections between reliable peers once they are found to be reliable and tries to disconnect unreliable peers, inactive connections and snubs peers that have no new data to trade.

Note the Reliable. You're after High Bandwidth Capacity, which is different. Reliable peers may have a lower bandwidth capacity than the unreliable peers.

Faster peers will become seeds quicker which can only benefit the swarm.

Until you realise the number of hit and runners that there are out there. Most of these peers will leave the swarm the instant they're done, stranding peers that aren't done yet.

Setting appropriate upload speed and slot count is irrelevant when determining connections between peers, that is done by chance.

Except that you're tying up connection slots on potentially reliable peers preventing new peers from getting decent connections.

A peer with low upload capacity is not considered reliable so it gets disconnected often.

Not necessarily. Its connection may be stable enough to provide prolonged upload to peers where a high-bandwidth peer may have the worst connection on the planet, disconnecting peers after as little as 1 piece downloaded.

[Switeck]

Switeck, is tit-for-tat meaningless as well? The BT protocol doesn't look for the fastest connection, it only keeps it when it finds one through chance. All connections are randomly created between peers, then the fastest ones are kept for as long as there's new data to exchange.

There is no true tit-for-tat in the BitTorrent protocol, and that is probably a GOOD thing. You do not get uploaded to on a 1-per-1 basis of how much you upload to someone else. Instead, it's like a race -- whoever's in the top 4 fastest upload places are who you'll be uploading probably the most. This can and often does change over the course of the torrent. But it's almost luck if the amount you upload to them is the amount you get back.

I said it 'looks' for the fastest uploader, I didn't say how ...or that it was likely to find it! It 'looks' using optimistic unchoke, as you said. Optimistic unchoke is also used to give new peers something to share, with a heavy weighting towards that goal.

[Martin Levac]

DreadWingKnight. Yes, note the reliable. Bandwidth capacity of a particular peer is also a factor in determining reliability. In fact the reverse is even more true. I'm not looking at high bandwidth capacity, I'm looking at similar bandwidth capacity between peers. The BT protocol already does that but it does it randomly. What I suggest would do the same thing but explicitly from the start. Would you prefer to maintain torrent speeds slow so that the slowest peer could get his fair share as well? As I said, low bandwidth peers are fucked by nature. There has always been leeches and there will always be leeches, nothing you or I do will change that.

"<Setting appropriate upload speed and slot count is irrelevant when determining connections between peers, that is done by chance.>

Except that you're tying up connection slots on potentially reliable peers preventing new peers from getting decent connections."

The BT protocol already works this way without the user's intervention. I've never connected to all seeds/peers on any torrent, no matter how many seeds/peers there were, no matter which BT client I used, no matter what settings I used.

Switeck. There is true tit-for-tat in BT but it's determined by the data you have, not by the bandwidth you have. Bandwidth capacity only determines how fast you can trade this data but as it is the nature of trading data, higher bandwidth capacity allows for new data to be gotten and to be given quicker.

Do you want fast or slow? Take a pick.

ML

[DreadWingKnight]

I want users to play nice.

If users play nice, all torrents become fast.

[tumu]

Going back to your original request and ignoring all the debating after that, I think your feature might only be helpful on very large swarms. And even taking that with a grain of salt to begin with.. There are just too many exceptions and issues to consider with the current torrent base (client and peer wise).

[Martin Levac]

If that suggestion is not feasible, I have another that would help many uTorrent users, slow and fast.

ML

[Switeck]

Switeck. There is true tit-for-tat in BT but it's determined by the data you have, not by the bandwidth you have. Bandwidth capacity only determines how fast you can trade this data but as it is the nature of trading data, higher bandwidth capacity allows for new data to be gotten and to be given quicker.

Then we're talking about a different thing.

If 2 peers have torrent chunks that the other doesn't have and they see each other in the swarm, they will probably connect at some point if nobody else gives them those pieces.

However even if bandwidth is available it will not all be allocated to the task. From what I've seen, no single peer ever gets more than about 60% of my upload bandwidth even when I've set upload slots to 3. Usually, no single peer gets more than 40% of my bandwidth for more than 10 seconds. This is even if they are uploading to me far faster than I can return the favor and nobody else is uploading more than 1/4 of that speed to me. That's obviously working as designed, but since there's no trading ratio demanded or expected it's not a true tit-for-tat. The end result is I may get 20+ chunks from the 1 peer but only upload 5 in return.