The list order is the recommended order of implementation.
If you want to contribute to one task but there is no issue yet or want more info feel free to ask for more information.
Introduction
I've recently added three new tools to the repo. These three console commands can be used for testing and debugging. Since I started working on this project, I've missed tools that can help developers and sys admins detect and fix trackers' problems. The new three console commands are:
HTTP Tracker Client
This client allows making announce and scrape requests to HTTP trackers.
Announce:
cargo run --bin http_tracker_client announce http://127.0.0.1:7070 9c38422213e30bff212b30c360d26f9a02136422
Notice: all parameters except the info_hash are hardcoded. This client is not intended (yet) to be used with a full request from inputs. It's only used for testing so it generates a sample request. It could be changed to accept all parameters as a json object in the future. It depends on this.
You could use any browser for the HTTP Tracker Client, but the main advantage is getting the response in JSON instead of Bencoded format.
Scrape:
cargo run --bin http_tracker_client scrape http://127.0.0.1:7070 9c38422213e30bff212b30c360d26f9a02136422
Notice: this is fully implemented as the only parameter for the scrape request is the info_hash.
This client is very convenient because there is no easy way to build and send UDP packets. And some BitTorrent clients don't show you the Tracker response. (https://www.biglybt.com/ does it).
Tracker Checker
You can use this command to test running services on trackers. It can check:
UDP trackers: it makes an announce and scrape request.
HTP trackers: it makes an announce and scrape request.
HTTP endpoints (health check endpoints): it makes a GET request to the provided endpoint and checks that the endpoint returns a 200 HTTP status code.
Running checks for trackers ...
UDP trackers ...
✓ - Announce at 144.126.245.19:6969 is OK
✓ - Announce at 144.126.245.19:6969 is OK
HTTP trackers ...
✓ - Announce at https://tracker.torrust-demo.com/ is OK
✓ - Scrape at https://tracker.torrust-demo.com/ is OK
Health checks ...
✓ - Health API at https://tracker.torrust-demo.com/health_check is OK
Considerations
This code is still in beta, some parts were moved from testing code to production code. For example the UdpClient. That means it's not covered by tests. We should add tests while we implement all these new features. I merged as it is because I wanted to use the Checker in the testing workflow (E2E tests). I wanted to enable this feature asap to avoid regressions when we merge PRs, since a lot of the bootstapping of the app is not covered by unit tests.
This is an epic issue for tracking progress with clients.
NOTES:
Introduction
I've recently added three new tools to the repo. These three console commands can be used for testing and debugging. Since I started working on this project, I've missed tools that can help developers and sys admins detect and fix trackers' problems. The new three console commands are:
HTTP Tracker Client
This client allows making
announce
andscrape
requests to HTTP trackers.Announce:
Notice: all parameters except the
info_hash
are hardcoded. This client is not intended (yet) to be used with a full request from inputs. It's only used for testing so it generates a sample request. It could be changed to accept all parameters as a json object in the future. It depends on this.You could use any browser for the HTTP Tracker Client, but the main advantage is getting the response in JSON instead of Bencoded format.
Scrape:
UDP Tracker Client
This client allows making
announce
andscrape
requests to UDP trackers.Announce:
Scrape:
Notice: this is fully implemented as the only parameter for the
scrape
request is theinfo_hash
.This client is very convenient because there is no easy way to build and send UDP packets. And some BitTorrent clients don't show you the Tracker response. (https://www.biglybt.com/ does it).
Tracker Checker
You can use this command to test running services on trackers. It can check:
announce
andscrape
request.announce
andscrape
request.GET
request to the provided endpoint and checks that the endpoint returns a 200 HTTP status code.You can run it for the local dev env with:
or for the live demo with:
Output:
Considerations
This code is still in beta, some parts were moved from testing code to production code. For example the
UdpClient
. That means it's not covered by tests. We should add tests while we implement all these new features. I merged as it is because I wanted to use the Checker in the testing workflow (E2E tests). I wanted to enable this feature asap to avoid regressions when we merge PRs, since a lot of the bootstapping of the app is not covered by unit tests.