Peer selection

[rodgerse]

Whats a protocol that can somehow filter the types of peers your connected to?.So, you can either ban and disconnect to a specific peer you see in your connections, or say will only except certain types of peers.

I don't mean to sound selfish, but I want to connect to as many high upload seeders/leechers as possible, weeding out the ones that give nothing, have nothing or just leech and take up a valuable peer connection.

Ip block lists would help, but you'd have to find every bad peer and ad the ip.I think peer guardian only works in that fashion.

So is there a program or something that can block based on share ratio or Up speed, or even % complete as to only connect to seeders, or any other method of blocking someone that doesn't involve you manually telling the program to?.

[DreadWingKnight]

Just because they aren't uploading to you, it doesn't mean they aren't uploading.

BitTorrent works best when you don't try to micromanage it like your request wants to allow you to.

[rodgerse]

I know, sometimes its because they'v maxed out most of their bandwidth to other peers, so they're not really bad.

but still, the point is they're not giving me anything and so I'm not going to waste a connection on them that I can use on someone with available bandwidth and high UP speed.

sorry, but getting rid of leeches that suck you dry and leave you with nothing I don't think is micromanaging.

[DreadWingKnight]

You may not think it's micromanaging, but it is.

This sort of management has been requested and rejected before.

[rodgerse]

So it was rejected purley for the the sake of controll people would have, even though many would find it practicall?.

Are there ways of implementation for it or not.

[Switeck]

It would fragment the torrent swarm, prevent rare pieces from getting traded, and eventually doom the whole system...if done automatically. So I *REALLY* don't think it will be implemented, ever.

If you want to add ips to your ipfilter.dat, go ahead...but it will generally drop your speeds in the long run.

Sometimes a peer with a lower percentage than you has nothing to give you...but if you don't upload to it some, then later it may not upload anything to you when it finally gets a rare piece that you don't have.

[rodgerse]

But who you upload to and how fast is random based on who you happen to connect to and your overall Upload limit.I

f I leech from everyone and give nothing, there's no way to be punished through what they'll give me, its random, most won't even remember it, let alone put me on they'r block lists.

If I happen to reconnect later to them after only taking, they would likely seed to me just as fast, if not more.

[Lord Alderaan]

Its not random. BitTorrent is a system that works because everybody follows the same rules. Yes it can be cheated but no single client would be able to prevent that without also hurting the innocent people. Cheating or unwanted leech behavior has to be solved by updating/improving the protocol not by giving individual users more control over which BitTorrent protocol parts they do and do not want to follow or who and who not to upload to.

And then we aren't even considering human stupidity. Such as people messing with settings they don't know the consequences off.

[rodgerse]

What you simpy call cheating is a way to get around one of the biggest flaws of BT.

Unless your on prvt tracker, there is no reason not to upload as little as possible and to simply close the program as soon as your DL finishes.

Frankly I'm just shocked at how long the protocol has survived, because theoretically its open and unrestrictive nature means every torrent would always have virtually no seeders and snail-like speed for even the most popular of popular torrents, there's just little or no incentive to give back anything and its really amazing how many people are willing to.Personally I'm waiting to close it while its edging %100 finish, while devoting any Up speed for the health of the connection only.

So if all the leechers aren't able to connect to others 'cause of auto detection, like I said, they'll be forced to seed/upload just to connect, therefore creating an actuall incentive to seed and improving swarm speed.

[Switeck]

You'll generally see why cooperation works on the huge torrents with few seeds. There, if you're not uploading (or uploading alot slower than others) then your download speed WILL SUCK. If you set upload speed to the 6 KiloBYTES/sec minimum to not be crippled by µTorrent's anti-leech and TCP/ip flow control regulations...you'll be lucky to hit 5-10 KiloBYTES/sec download speed, and often only in bursts. (The optimistic upload slots in action of various peers+seeds, in other words.)

Part of the success of BitTorrent is people's laziness. Even those that say they'll stop a torrent when it reaches 100% downloaded often forget about it and let it run for hours. That much seeding, even if not equaling what they downloaded, at least helps the swarm make up for the loss.

[Lord Alderaan]

Thats because the protocol is smarter then that. A little bit of leeching doesn't hurt the health of a torrent. BitTorrent was always intended to share popular data and with the current BT protocol popular torrents are virtually impervious to 'leechers'. Its when a torrent is used for rare or unpopular content that hit-n-run tactics and other 'leeching' behavior becomes a problem.

I guess u never heard of tit-for-tat (which is the system behind what Switeck explained above) stuff in the protocol.

Also it is trackers that implemented the whole upload till a ratio of 1 scheme. Which is a way to maintain a sort off fair system without too much rules and calculations. But there are better (but more complicated) ways to keep a torrent community running optimal. And of course you could ignore it all together and still have a working community, especially larger communities won't have any problems.

Someone with a high upstream doesn't (or shouldn't) mind having a higher ratio then someone who has less upstream. In fact the 1 ratio rule is a bit unfair towards people who do not have a high upstream.

That said there are indeed ways to improve the protocol. But giving more power to the people will make things WORSE, not better, and that is the reason why µtorrent doesn't allow you too much tweaking.

[Jorgepesa_44]

When initial seeding, i had face the case: where uploaded 7,5 Gb for a file of 4,3 Gb, no peer has more than 70% of the file. The top 10 peers are in less than 5% gap of availability to the first.

I porpose to create some kind of micromanagement of peers as follows:

When more than (lets say) 20% is spreaded, let initial-seeder to strong priorize to initial uploaders (lets say 5 or less) or those who has more parts uploaded. Then, avoid to upload to other peers the same part that these initial uploaders already have.

This priorized peers will acelerate the spreading speed to "secondary" peers and the seeds number increases. Also, this strategy probably will limit the spread of same parts many times and generate new seeds with less uploaded.

[DreadWingKnight]

Prioritizing most-complete peers encourages hit-and-running.

Initial-seed mode already does the ignoring of already-uploaded pieces.

The prioritization you're proposing will actually have the opposite effect on piece distribution that you're trying to achieve due to the asymmetric nature of residential connections.

[shawf]

What about auto detection of misconfigured clients and ban them temporarily. Some clients seems opening too much upload slots and download slots. Thus they uploading and downloading very thin. Like 0.3-0.5 KB/s. I have 19KB/s upload bandwidth and I don't open too much upload slots so peers can download from me around 5 - 8 KB/sec. And I can download from them with fair speeds. Isn't that expected behaviour? For small torrents it is not concerned so much. But for big torrents it can be annoying. To autodetect, after 1 hour active transfer, if average speed is below 1.0KB/sec client can auto ban temporarily for 1 day, or better solutions can be developed. In long term people may be forced to configure their clients to normal behaviour. And this may improve health of torrent swarms. Utorrent may count this slow rates uncounted. If there is 10 peers misconfigured and downloading uploading 0,5KB/sec it totals 5KB/sec. I would prefer use that bandwidth to properly configured clients.

[DreadWingKnight]

It's impossible to detect that actually.

[Jorgepesa_44]

Said: Initial-seed mode already does the ignoring of already-uploaded pieces.

I am now uploaded 8,70 GB for a 4,35 GB file and global availability is still on 1.801. Max. availability for other peers is 78,9%.

Repeated parts?

[jewelisheaven]

I saw your other post, it was more of a feature request. Why did you post here ...Initial seeding can't control peers disconnecting and taking their unique pieces with them.

Edit:

Due to popular demand... or something: The option to customize your queue.dont_count_slow_dl/ul has arrived. It can be found in the in-development version of uT 1.8 found at the Announcements forum.

It still defaults to 1 KiB, but you can change it as you see fit

[DreadWingKnight]

Could be:

Your system putting out hashfails for whatever reason.

Initial seed mode not actually on.

Peers disappearing making old pieces appear less visible.

There have been changes to the initial seeding algorithm in the 1.8 line that may change the behavior you're seeing.

[Jorgepesa_44]

Ok. lets wait to 1.8 in the initial-seeding subject. Initial-seeding is on.

But other issue initiated above: Prioritizing most-complete peers may encourages hit-and-running.

But as soon as 5 guys achieve 80-90% they will spread out many parts so fast. The critical limit is the uplink band on the initial-seeder to have a 2nd seed; but if 3 or 4 people are very close to 100% al the same time, most probably some will stay seeding for a while. Others peers may be 10-20% below those "privileged" but no so far: they have at least half dozen of good part-providers not only the initial seeder repeating the same part.

The trick to reduce the efect for hit-and-run may be start the "priorization rule" only if there are a minimum number of peers connected (lets say 25); probably some privileged peers will keep seeding when they download so fast.

Is it possible to simulate the situation in some way?.

Anyway, thanks for uTorrent. It is great!.

[DreadWingKnight]

But as soon as 5 guys achieve 80-90% they will spread out many parts so fast.

MAYBE only to each other.

Optimum speed will be achieved by sending the rarer pieces out to the lower complete peers rather than the higher complete ones, since it will FORCE those higher complete peers to share with the lower complete peers in order to be able to complete.

Minimum number of connected peers doesn't help things.

Neither does anything else that prioritizes high-complete peers.