Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to add a global tracker list? #591

Open
BoyFaceGirl opened this issue Jan 4, 2023 · 5 comments
Open

How to add a global tracker list? #591

BoyFaceGirl opened this issue Jan 4, 2023 · 5 comments

Comments

@BoyFaceGirl
Copy link

How to add a global tracker list? It is troublesome to add torentmanager circularly each time. If all torents use the same tracker, it is unnecessary to add them separately each time, for example, in the ClientEngine class? Can I automatically read the tracker when I start downloading?

@ManlyMarco
Copy link

ManlyMarco commented Feb 3, 2023

I don't think that's possible, each TorrentManager handles its own trackers without input from ClientEngine. You need to do something like this:

foreach (var torrentManager in clientEngine.Torrents)
{
    torrentManager.TrackerManager.AddTrackerAsync(...);
}

It's not as convenient but it's not that bad. If you had global trackers then how would you handle private torrents? This way you can check if it's private and act accordingly (or let it throw if there should be no private torrents).

@BoyFaceGirl
Copy link
Author

I don't think that's possible, each TorrentManager handles its own trackers without input from ClientEngine. You need to do something like this:

foreach (var torrentManager in clientEngine.Torrents)
{
    torrentManager.TrackerManager.AddTrackerAsync(...);
}

It's not as convenient but it's not that bad. If you had global trackers then how would you handle private torrents? This way you can check if it's private and act accordingly (or let it throw if there should be no private torrents).

If there are 100 TorrentManagers, the Tracker is the same, which will cause a serious waste of resources?

If there are 100 TorrentManagers, the Tracker is the same, which will cause a serious waste of resources. Or add a static TrackerManager. It is also convenient to automatically read TrackerManager when TorrentManager starts

@alanmcgovern
Copy link
Owner

From an efficiency perspective, the existing API is probably as good as it gets. There's a certain amount of data that has to be stored on a per-torrent basis, and that's what's stored in the Tracker class.

The expensive part, maintaining an efficiency set of Http resources, should be handled by HttpClient internally. The latest iterations of this code share the same underlying Http handler object in all copies of HttpClient, which is (according to the docs) the best way to minimize resources.

The other way of thinking about it is that if I were to implement a global tracker list, I'd implement it by adding a List to ClientEngine, and whenever a new TorrentManager is added to the engine it would just call:
Manager.TrackerManager.AddTrackerAsync.

This is a unique/unusual enough request that adding additional API to the library to support this doesn't make a huge amount of sense to me. Based on the info above, does that seem reasonable?

Also, are you seeing resource issues when adding many trackers to the engine? I could imagine there being a lot of overhead if there are many trackers.

@BoyFaceGirl
Copy link
Author

From an efficiency perspective, the existing API is probably as good as it gets. There's a certain amount of data that has to be stored on a per-torrent basis, and that's what's stored in the Tracker class.

The expensive part, maintaining an efficiency set of Http resources, should be handled by HttpClient internally. The latest iterations of this code share the same underlying Http handler object in all copies of HttpClient, which is (according to the docs) the best way to minimize resources.

The other way of thinking about it is that if I were to implement a global tracker list, I'd implement it by adding a List to ClientEngine, and whenever a new TorrentManager is added to the engine it would just call: Manager.TrackerManager.AddTrackerAsync.

This is a unique/unusual enough request that adding additional API to the library to support this doesn't make a huge amount of sense to me. Based on the info above, does that seem reasonable?

Also, are you seeing resource issues when adding many trackers to the engine? I could imagine there being a lot of overhead if there are many trackers.

Many times I really need to add a lot of trackers. Many times the. torrent file found on the Internet is not as easy to download as Ubuntu. torrent. The tracker servers inside. torrent may all fail. Even if the ubuntu. torrent file does not have any download speed when I do not add additional trackers, it is not representative to use ubuntu. torrent to test some times because this file is hot enough. However, files with high popularity do not need to be downloaded through p2p at all, which is very helpless.

I think it is very necessary to have a convenient and fast tracker api, especially when there are many download tasks.

          // read from  local  tracker.txt
            List<Uri> uriList = new List<Uri>(100);// 100  tracker addr

            ClientEngine engine = new ClientEngine();
            foreach (var torrentManager in engine.Torrents)// 30  torrents
            {
                for (int i = 0; i < uriList.Count; i++)
                {
                    await torrentManager.TrackerManager.AddTrackerAsync(uriList[i]);
                }

            }
            await engine.StartAllAsync();

            // add new torrent 

            var newTorrwnt = await engine.AddAsync(MagnetLink.Parse("xxxxx"), Path.Combine(Environment.ProcessPath, "downloan"));

            for (int i = 0; i < uriList.Count; i++)
            {
                await newTorrwnt.TrackerManager.AddTrackerAsync(uriList[i]);
            }

            var newTorrwnt2 = await engine.AddAsync(MagnetLink.Parse("xxxxx"), Path.Combine(Environment.ProcessPath, "downloan"));
            ...
            var newTorrent30 = ...

          // if  tracker.txt changed,add tracker addr

                uriList = new List<Uri>(200);// 100  tracker addr,read from local track.txt
            foreach (var torrentManager in engine.Torrents)// 30  torrents
            {
                for (int i = 0; i < uriList.Count; i++)//200
                {
                    await torrentManager.TrackerManager.AddTrackerAsync(uriList[i]);
                }

            }

Real use scenarios are often complex. Tracker and torrent will be added at any time. Every time, it is necessary to cycle TorrentManager. Both efficiency and use experience are poor

@ManlyMarco
Copy link

I think you might confused on a few points.

Adding random trackers to random torrents is not going to accomplish anything, especially if they are not seeded by many people since it's unlikely that they would add the same custom trackers as well. True, this was something you had to do in the early days of torrenting, but introduction of DHT and peer exchange made public trackers mostly obsolete outside of indexing and keeping statistics. It's common these days for torrents to have 0 trackers if they are shared as magnet links and they download just fine even if there's only a single seed, at the cost of participating in the DHT network (which monotorrent does by default).

"Hot" files are excellent for sharing via torrent since each client contributes upload bandwidth, removing the need for an expensive download server. "Cold" files are much more suited to be shared by direct download since that way you don't rely on random seeds staying up.

What he meant by efficiency was computational efficiency of adding trackers, not efficiency in terms of code lines to accomplish. I don't get what the issue is with the foreach approach, it's barely more code and it's not like you have to write this code every time you add a torrent, in fact you could have probably wrote it in the time it took you to read this reply.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants