I run a private tracker with (currently) 4 peer. One peer continuously generates files, the others continuously download. (Continuously means: automatically/by script)
While 3 peers are always online, one goes offline regularly and then tries to download those file he “missed” in his absence.
About 1/3 of torrents on that peer remain “Downloading 0.00%” forever. I tried many setting options (on that peer) to no avail.
This is my hypothesis: the peer must have a lower share ratio than the others.
Where do I find the (overall) share ratio?
Is the peer “punished” for being less cooperative?
Can I change settings in the torrents, the tracker or (the other) peers, so that a low share ratio is disregarded?
Thx
“Downloading 0.00%” forever … How to disregard share ratio?
-
- Member
- Posts: 15
- Joined: Sat Oct 18, 2014 1:44 pm
-
- Member
- Posts: 15
- Joined: Sat Oct 18, 2014 1:44 pm
Re: “Downloading 0.00%” forever … How to disregard share rat
I intend to build a software installer distribution system on P2P for a corporate network.
Software deployment is and will be centrally managed (a user orders software, order must be approved, etc. etc., order is centrally distributed, etc. etc.)
All installers shall remain active torrents, even after uninstall.
As a result, popular software installers will have many copies, rare software few copies.
Only system administrators can add a torrent (software installer) to the system.
Users are and will be unaware of the distribution.
The system in catch phrases:
- Every leecher becomes a seed
- Altruistic by design
- Enforced altruism
- Seeder without a choice
- Free ride impossible
- Share all
- Must share
- Always open
- Centrally managed
- Only torrents nobody will ever use again are removed
It shall not matter if a client has ever shared, he will in the future because he has no choice.
The user cannot influence sharing (except by taking the client offline).
The system will run as a Windows system service.
Salt will be used for signalling and diagnosis.
The system has no need for Tit-For-Tat.
In fact, Tit-For-Tat is detrimental, because the history of a client must not impact network utilisation.
Therefore I need to get rid of Tit-For-Tat.
This is a problem, because the "real world" use of BitTorrent cannot do without Tit-For-Tat.
I hope that I the vast array of libtorrent options offer enough flexibility to "mute" the intrinsic Tit-For-Tat properties of the BitTorrent protocol.
A first attempt will increase the optimistic unchoke limit.
I continue to screen literature but have so far not found an active project alike, so I welcome any suggestion or comment.
Kind regards,
Markus
Software deployment is and will be centrally managed (a user orders software, order must be approved, etc. etc., order is centrally distributed, etc. etc.)
All installers shall remain active torrents, even after uninstall.
As a result, popular software installers will have many copies, rare software few copies.
Only system administrators can add a torrent (software installer) to the system.
Users are and will be unaware of the distribution.
The system in catch phrases:
- Every leecher becomes a seed
- Altruistic by design
- Enforced altruism
- Seeder without a choice
- Free ride impossible
- Share all
- Must share
- Always open
- Centrally managed
- Only torrents nobody will ever use again are removed
It shall not matter if a client has ever shared, he will in the future because he has no choice.
The user cannot influence sharing (except by taking the client offline).
The system will run as a Windows system service.
Salt will be used for signalling and diagnosis.
The system has no need for Tit-For-Tat.
In fact, Tit-For-Tat is detrimental, because the history of a client must not impact network utilisation.
Therefore I need to get rid of Tit-For-Tat.
This is a problem, because the "real world" use of BitTorrent cannot do without Tit-For-Tat.
I hope that I the vast array of libtorrent options offer enough flexibility to "mute" the intrinsic Tit-For-Tat properties of the BitTorrent protocol.
A first attempt will increase the optimistic unchoke limit.
I continue to screen literature but have so far not found an active project alike, so I welcome any suggestion or comment.
Kind regards,
Markus