IPv6 trackers

[Phentora]

Could a IPv6 list be added also ? There are a few trackers that support IPv6 only as far as i am aware.

[ngosang]

Sorry, the server running the bot doesn't have IPv6 connectivity.

[HarryS]

Are you not willing to set up a v6 tunnel on your server, or is there some other limitation?

Over 20% of the connections to Google services are via IPv6. This percentage doesn't even include the large number of users who have limited v6 connectivity (eg Teredo) -- because browsers prefer v4 over Teredo, whereas BT clients will still gladly use Teredo if it's enabled on their system.

Even though basically everyone still has v4 connectivity, v6 trackers are extremely beneficial, especially for clients who don't have proper v4 port-forwarding. Someone behind a NAT can often still use Teredo and receive direct incoming connections, giving a healthier peer swarm.

So yeah, I hope you can take v6 into more consideration. Thanks for your time.

[ngosang]

I can set up the tunnel but I don't know any IPv6 tracker. @HarryS @JanPokorny @xiuluo do you have any?

[Phentora]

I have IPv6 available on my VPS, but i haven't enabled it on the server side. I will make a issue when i do enable it.

[JanPokorny]

This should be ipv6 only, haven't tested: http://tracker.ipv6tracker.ru/announce

[HarryS]

Sounds cool! Here's mine:
udp://ipv6.tracker.harry.lu:80/announce
http://ipv6.tracker.harry.lu:80/announce

(udp is preferred, but you can add both to the list)

[francisuk1989]

udp://IPv6.open-internet.nl:6969/announce

Heres is another one from leechers-paradise/eddie4 that supports IPv6

[Power2All]

yeah, gbitt.info handles IPv4 only.
OpenTracker has no IPv6 support yet, but if anybody knows a IPv6 supported OpenTracker, would be appreciated. Otherwise I need to fork it and hack a IPv6 support to it.

[theel0ja]

Open sourcing the update bot could help people add IPv6 support.

[Power2All]

OpenTracker is already open sourced on Github.

[ngosang]

Open sourcing the update bot could help people add IPv6 support.

@theel0ja I made this project because all list I found in Google were outdated. Publishing the source code will lead to more abandoned forks and more outdated lists. I will keep updating the list and, if I can't at some point, I will release the source code.

[JanPokorny]

@ngosang Outdated lists can be created pretty easily now, just copy the current list 😄 Also, look at how many project are on GitHub and how many of them are seriously hurt by "abandoned forks" (only ones I know of are illegal ones like Popcorn Time)

[mikaeldui]

@ngosang I'd be willing to reverse engineer the bot and then add IPv6 compatibility. (work started at https://github.com/mikaeldui/TrackerListBot)

[crimist]

If you want somewhere to submit your IPv6 tracker in the meantime https://newtrackon.com/ supports it.

[theel0ja]

Outdated lists can be created pretty easily now, just copy the current list

Saw many posts around the internet doing that, sadly.

[tim1103]

Sorry, the server running the bot doesn't have IPv6 connectivity.

You may be able to use GitHub Action?

[ngosang]

@Power2All this is not the place. We only list public trackers, not software.

[ngosang]

You may be able to use GitHub Action?

Maybe, but I will lose the control about the DNS blocks, latency...
I will implement this in the future, by now I think all trackers but 3 or 4 have dual IP stack. Using the IPv4 list in a IPv6 only client will be still very useful.

[Br31zh]

yeah, gbitt.info handles IPv4 only.
OpenTracker has no IPv6 support yet, but if anybody knows a IPv6 supported OpenTracker, would be appreciated. Otherwise I need to fork it and hack a IPv6 support to it.

I didn’t see anyone contradict this, so I’m doing it.

OpenTracker support IPv6 since a long time ago (before 2018 at least, the first time I checked), but you have to rebuild it from source (with a flag, as explained here), and it’ll be IPv6 only. On my tracker I run two OpenTracker daemons, one IPv4 only and one IPv6 only, on the same computer and same port. For now it seems to works as intented with this setup.

[Power2All]

yeah, gbitt.info handles IPv4 only.
OpenTracker has no IPv6 support yet, but if anybody knows a IPv6 supported OpenTracker, would be appreciated. Otherwise I need to fork it and hack a IPv6 support to it.

I didn’t see anyone contradict this, so I’m doing it.

OpenTracker support IPv6 since a long time ago (before 2018 at least, the first time I checked), but you have to rebuild it from source (with a flag, as explained here), and it’ll be IPv6 only. On my tracker I run two OpenTracker daemons, one IPv4 only and one IPv6 only, on the same computer and same port. For now it seems to works as intented with this setup.

This is a old thread, I've already switched to my own GO app.
OpenTracker does support IPv6 only on TCP, not UDP.
My code does support IPv6 with UDP.

[Br31zh]

I’ve set qBittorrent to only use IPv6 (and even set the tracker with it’s IP instead of domain to be sure) and it seems to work on UDP (all trackers without IPv6 support are marked as "Not working"). If you have better way to check it, I can try it.

"En fonction" mean Working in french: https://fichiers.breizh.pm/Images/Screenshots/2021-05-09-023732_1150x30_scrot.png

[styromaniac]

Open sourcing the update bot could help people add IPv6 support.

@theel0ja I made this project because all list I found in Google were outdated. Publishing the source code will lead to more abandoned forks and more outdated lists. I will keep updating the list and, if I can't at some point, I will release the source code.

Isn't your project the most starred? People don't automatically resort to using forks. They use what's the most popular. I suggest getting over your fear of forks so IPv6 connectivity finally makes it into your project.

[rautamiekka]

Open sourcing the update bot could help people add IPv6 support.

@theel0ja I made this project because all list I found in Google were outdated. Publishing the source code will lead to more abandoned forks and more outdated lists. I will keep updating the list and, if I can't at some point, I will release the source code.

Isn't your project the most starred? People don't automatically resort to using forks. They use what's the most popular. I suggest getting over your fear of forks so IPv6 connectivity finally makes it into your project.

Agree. GH may be complicated, but even then it's easy enough to find an active fork even if it's a long tree of forks.

[ngosang]

Isn't your project the most starred? People don't automatically resort to using forks. They use what's the most popular. I suggest getting over your fear of forks so IPv6 connectivity finally makes it into your project.

I'm not afraid, that is not the reason. I spent several hours a day working in open source projects for free, you can take a look at my profile.

This project has become "de facto" standard for public trackers. It's used by qBittorrent, Jackett, *arr stack and several huge public Bittorrent sites because they know me and they trust me. If any of the trackers in the list is compromised it will be a big security risk because they can track your IP and the torrents you are downloading. That could happen, of course, but I will be notified and I will take actions. They also need a reliable list of trackers to keep the Bittorrent swarm alive as long as possible. Those are other reasons to avoid fragmentation, forks, copycats...

The source code is just 200 lines of Python code. Publishing the source code is not going to fix the IPv6 issue in this fork. The value of this project is my hardware and the CI/CD stack that updates the list every day since 6 years ago. I want to add this feature but my ISP does not provide IPv6 connectivity. I have to deal with tunnels, Docker networks and improvements in the code to not mix IPv6 and IPv4 trackers. Is not that hard but the "big projects" using this project can't use IPv6 lists and the priority is low.

Any of you could tell me if the IPv4 ALL list is working in a IPv6 network? Which trackers are not working? What will be the proposal to include IPv6 trackers? Just a new list with IPv6 trackers? I can't mix IPv6 trackers in the current lists.

[Power2All]

Wouldn't it not be better to convert the Python code over to GO?
It's much more performant, build-in libraries are easier in use then in Python.
Has full IPv6 support out of the box, and supports TCP/UDP connectivity.
Currently I'm almost done with my Announce server that uses both TCP and UDP, in IPv4 and IPv6 modus.
Just currently properly coding the structs in combination with compression (gzip) for less memory usage, but still optimal speed.

[rautamiekka]

Wouldn't it not be better to convert the Python code over to GO? It's much more performant, build-in libraries are easier in use then in Python. Has full IPv6 support out of the box, and supports TCP/UDP connectivity. Currently I'm almost done with my Announce server that uses both TCP and UDP, in IPv4 and IPv6 modus. Just currently properly coding the structs in combination with compression (gzip) for less memory usage, but still optimal speed.

There couldn't possibly be any benefit converting it, and that's not even counting having to learn a weird new language.

[Power2All]

There couldn't possibly be any benefit converting it

Didn't I mention performance-wise as a benefit ? Not to mention better threading and memory consumption ?

and that's not even counting having to learn a weird new language.

I've done it, so can you and anybody else.
The language isn't that much different comparing it towards C, PHP and even Python though.
In fact, it's even much more readable then Python by a long shot...

[rautamiekka]

The whole point is the extra performance couldn't possibly be useful for the software in question.

[Power2All]

The whole point is the extra performance couldn't possibly be useful for the software in question.

Actually, it does.
When you have a app that does it's work in a hour, and most of the time it's busy parsing, but if you can speed up the parsing of all the data that is gathered (at that point, the connection is the slowest part of the process, so why not first deal with the access to all the connections one by one, gathering the data, and then parse it), and then generate the output data, there would be a huge speed improvement.
I know where you're getting at, but that's a pointless discussion, as any performance improvement, is a improvement.
It would be even better when your code is even more readable, so that you could work simpler in the future on your code.

I've improved the same exact parsing method for someone else, that did it in a hour, by connecting each loop to a URL, parsing it, and so on, by just first connecting to all the needed URL's, gathering the data, and after that parsing it. Went from a hour of work, to just over 20 minutes...

[ngosang]

Kids, this is not the place. I will mark as hidden the next comments regarding to programming but I let you some words.
The requirements for this project are:

• The trackers could be HTTP, HTTPS, UDP, WS, WSS => Those protocols are supported by most languages but not all. From my knowledge: Go, Python, NodeJS, C#, Java, C/C++, Rust... all will be suitable
• Scrape 500 trackers and publish the result in less than 24 hours => You can accomplish that in any language
• Run in the hardware available => I have access to almost unlimited resources

Said that, there is no point in doing weird things. If I have to write the code from scratch I will chose Go because the good support for parallelism (go-rutines), network protocols support and low resources consumption. This project has 6 years and Go was not a thing at that time. Python is good enough and I don't want to spend time rewriting something that works. I prefer to spend my time in the other 30 opensource projects I work for.

Details about current implementation:

• In 6 years I only touched the code 5 times: Python2 => Python3 port, parallelism rewrite, Dokerization, log traces standardization (for my central log system), push notifications (for my alert system).
• The first implementation was a dirty Python2 script running in a RaspberryPi with a Cron task. If was slow AF because it didn't use parallelism. In any case, it was working for 2 years without maintenance, in fact I did not know where the Raspberry was for a few months and it worked the same (I forgot in a rental apartment and the next tenant paid the bills without knowing it).
• I rewritten the code to use multi-threads. I know what you are going to say about Python GIL, not real threads... but that is not important for this project because the bottleneck is in the I/O no the CPU. With a simple thread pool implementation the execution time decreased from 2 hours to 1 minute. The current implementation has been the same for 4 years.
• I did an experiment with async/event-loop programming but it was not good enough. The scrapping time was the same, the memory usage was half (10MB RAM) the code was a bit ugly because I have to wrap some libraries without async support.
• The current implementation takes 1 minute and 10 seconds in scrapping 500 trackers. It uses 16 MB of RAM and 1% of CPU for 1 minute. You can not improve any of those metrics in a significant way using other language because the critical path for scraping 1 tracker is (10s scrape timeout * 3 retries + 10s IP scraping timeout * 3 retries ... that is 50s of waiting for the worst tracker...) Finishing the async code and writing just one transaction to the SQLite3 database I can reduce the time to 52-55s or so... maybe when I deal with IPv6 issue...