Transmission

x190 wrote:

(I've watched some for more than 5 minutes)

For example, you could shorten this by changing "MAX_UPLOAD_IDLE_SECS = ( 60 * 5 ),"

That's not the problem. There are plenty of peers, and the ones I am watching are not idle, I am uploading to them, but they are not allowing me to download. It is like they have been optimistically unchoked, but they are not re-choked after a few tens of seconds as I would expect. Transmission should re-choke them in less than a minute and then do an optimistic unchoke on another peer.

lazybones wrote:joewill you forget that when you joing a swarm you start with nothing. Meaning that if we took your suggestion it would be next to impossible for you to get any parts since other peers with parts would be favoring each other and would keep you from being able to get into any of their download slots since you where not sharing with them.

Please stop posting nonsense. You are obviously clueless.

x190 wrote:

make changes as you wish or even rewrite it completely.

Methinks thou dost protest too much, joewill! If you think you have a logical case for a better algorithm, then open a trac ticket. Otherwise, stop annoying everybody that tries to help you.

If the people who were trying to help me knew what they were talking about, then I would not "protest".

I am NOT asking for a "better algorithm". Just basic bittorrent functionality.

Do you know how the standard bittorrent algorithms are supposed to work? Do you understand unchoking and optimistic unchoking?

If not, how can you possibly think you can "help" me?

Look, I'll help you a little, since you seem to need it.

Bittorrent algorithms are based on a tit-for-tat strategy. Some number of peers are unchoked (means we will upload to them), but other peers are checked periodically to see if they are giving me a higher download rate. If a better choked peer is found, then the worst of the unchoked peers is re-choked, and the new peer is unchoked. So, obviously, if there are other peers who will let me download, peers that I am uploading to ("unchoked") but will not let me download should only last for a few tens of seconds before they get choked.

Except for optimistically unchoked (OU) peers. The purpose of OU is to prevent a situation where no one will upload to anyone else. An OU will upload to a peer for a while (several tens of seconds, usually less than a minute) to see if that peer will eventually let us download. If not, they are re-choked.

The problem with Transmission is that I am seeing peers that I am uploading to, but will not let me download, but Transmission keeps uploading to them indefinitely (more than 5 minutes). You can see in your code snippet that it should not go on for more than 40 seconds (4 x 10sec). I guess the problem is that Transmission unchokes all peers, or at least a large number of them. I do not see any way to configure the number of peers Transmission unchokes. The default for BitTorrent was four.

x190 wrote:Since you are an expert, write your own code! I am totally uninterested in your lectures.

I'm not even close to an expert, all of what I have written is extremely basic bittorrent functionality. Anyone with a rudimentary knowledge of bittorrent should already know it, and not require lectures. Amazing that you feel qualified to "help" me and do not know it, when this information can be found easily with a web search.

But if you are not interested in even knowing the basics of how bittorrent works, why are you posting in this thread? Please let someone who knows what they are talking about post, and stop lowering the SNR of this thread.

x190 wrote:As a famous Canadian Prime Minister once said: Fuddle Duddle!

That applies to you more than me. Please take your own advice. I already asked you politely to refrain from posting about things that you do not understand in my thread. It just lowers the SNR and makes people who do know what they are talking about less likely to post.

Just one question left.

Have you made sure that no other peer can actually utilize that upload bandwidth "better" than the one who is not letting you download? If not made sure, or more importantly, no other peer can make "better" use of it then I see no reason to let that one have the "left over" bandwidth so it can become a seeder quicker.

blacke4dawn wrote: Have you made sure that no other peer can actually utilize that upload bandwidth "better" than the one who is not letting you download? If not made sure, or more importantly, no other peer can make "better" use of it then I see no reason to let that one have the "left over" bandwidth so it can become a seeder quicker.

Pretty sure. When I add the no-DL peers IPs to my blocklist and restart Transmission, the other peers usually immediately start utilizing the additional UL bandwidth.

joewill wrote:

blacke4dawn wrote:So let me get this straight? You want to limit the upload speed to peers that don't allow download to the same peer and you say that that will make the cloud more "healthy"?

I'm not sure who you are quoting ("healthy"), but yes, the ones that have parts that I need, and that I am uploading to, but will not allow me to download, should get less upload bandwidth from me as compared to the peers that are letting me download from them.

This will obviously improve the efficiency of the swarm, statistically. Surely you can see that?

---

There is no way to know, that, and on the average, you could easily be wrong....

Consider:
Content each client has varies as to whether or not it is uniq or something someone else has. so uniq, vs. not.

Now consider a torrent of 100 parts,

P1 has #1-25, 51-100 (75% total) Connection = 1Mb/3Mbps (U/D)
P2 has #1-10, 26-60 (40% total) Connection = 2Mb/6Mb
P3 has #1-10, 51-70 (30% total) Connection = 2Mb/2Mb

How would you solve the above so that the largest percentage of the swam gets a complete copy
most quickly?
If you solved it for being done most quickly, would it be a different answer?

I think if you solve for either case, you'll see the reason for the current setup.

I know the first case (largest % of swarm has complete copies...(though smart clients hold back some small bit until they
are equally seeded so P1 doesn't go away after getting their 25%...)... but doing such hurts the bottom line due to 'mistrust'...
So most clients don't do that. They just assume others will be there to seed for them over time...may take a while, but...

Every user can set the number of slots manually in the client's "Preferences".
I see many leachers who must have set their number of upload slots to perhaps zero
and have even up to 80% of the torrent, and yet provide my with zero download.
So what do I do?
I permanently block them!!!
All you do is right-click on such a leacher, and select Ban Peer
Problem solved!