You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This has for consequence, if you want to rely on multiple tiers (better
robustness), that if you have only one seeder, this one could be unreachable by
a potential leecher. The reason is the suffle introduced in the tier by the client.
For this reason, it seems to me to be important to be able to configure many
tiers to be able to force the bittorrent clients to try trackers in a specific
and predifined order.
I know this multitracker feature only since yesterday.
I dicovered it by investigating why time to time clients are not able to join my
superseeder, and mainly use the webseed.
So I'm not a bittorrent expert and although It seems to me that the first
alternative should be what people mainly need, I won't say this should always
work like that.
I think we have also to take care to not change the meaning of the
"MirrorBrainTorrentTrackerURL" directive.
So, IMO this should be configurable.
You could maybe add a new Apache directive. Something like
"MirrorBrainNewTorrentTrackerTier" which would allow to split groups of
trackers/MirrorBrainTorrentTrackerURL directives
Newline between different URLs for same tracker, double newline for new tracker.
MirrorBrain puts all trackers together, so they are treated as a single tracker.
This is an actual bug, not a feature request.
Issue migrated (2015-06-05) from old issue tracker http://mirrorbrain.org/issues/issue86
msg329 (view) Author: Kelson Date: 2011-03-10.12:51:51
Mirrorbain seems to always put the trackers, in case of multitrackers, in one
and unique tier.
See doc:
http://www.scribd.com/doc/13839289/BitTorrent-MultiTracker-Specification
This has for consequence, if you want to rely on multiple tiers (better
robustness), that if you have only one seeder, this one could be unreachable by
a potential leecher. The reason is the suffle introduced in the tier by the client.
For this reason, it seems to me to be important to be able to configure many
tiers to be able to force the bittorrent clients to try trackers in a specific
and predifined order.
msg330 (view) Author: poeml Date: 2011-03-10.20:30:45
Hm, let me see if I understand correctly.
MirrorBrain 2.15.0 does the following:
% curl -s 'http://download.services.openoffice.org/files/stable/3.3.0/OOo-
SDK_3.3.0_Solaris_Sparc_install_en-US.tar.gz.torrent' | bdecode | grep announce
{'announce': 'http://bt.mirrorbrain.org:8091/announce',
'announce-list': [['http://bt.mirrorbrain.org:8091/announce',
'udp://bt.mirrorbrain.org:8091/announce']],
Are you proposing to use the form
instead of
?
Is that generally better, or should it be configurable?
msg331 (view) Author: Kelson Date: 2011-03-11.08:34:12
I think you understand well what I mean.
I know this multitracker feature only since yesterday.
I dicovered it by investigating why time to time clients are not able to join my
superseeder, and mainly use the webseed.
So I'm not a bittorrent expert and although It seems to me that the first
alternative should be what people mainly need, I won't say this should always
work like that.
I think we have also to take care to not change the meaning of the
"MirrorBrainTorrentTrackerURL" directive.
So, IMO this should be configurable.
You could maybe add a new Apache directive. Something like
"MirrorBrainNewTorrentTrackerTier" which would allow to split groups of
trackers/MirrorBrainTorrentTrackerURL directives
msg416 (view) Author: nemobis Date: 2013-02-20.08:58:24
To clarify, from a UI perspective, uTorrent, Transmission and so on show
different trackers with their backup URLs like this:
udp://tracker.publicbt.com:80/announce
http://tracker.publicbt.com:80/announce
udp://tracker.openbittorrent.com:80
http://tracker.openbittorrent.com/announce
Newline between different URLs for same tracker, double newline for new tracker.
MirrorBrain puts all trackers together, so they are treated as a single tracker.
This is an actual bug, not a feature request.
msg417 (view) Author: poeml Date: 2013-02-24.09:39:24
Thanks, I should look at it...
(end of migrated issue)
The text was updated successfully, but these errors were encountered: