LBRYCommunity/tracker
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity

lint: lint markdown files

Browse source
This commit is contained in:
Jimmy Zelinskie 2022-01-15 13:03:41 -05:00
parent 6e2c095ce4
commit c28d7ad788
6 changed files with 32 additions and 26 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
.markdownlint.yaml Normal file
View file

@ -0,0 +1,3 @@
---
line-length: false
no-hard-tabs: false

6
CONTRIBUTING.md
View file

@ -1,3 +1,5 @@
# How to Contribute
## Discussion ## Discussion
Long-term discussion and bug reports are maintained via [GitHub Issues]. Long-term discussion and bug reports are maintained via [GitHub Issues].
@ -55,7 +57,7 @@ All files should have `gofmt` executed on them and code should strive to have fu
We follow a rough convention for commit messages that is designed to answer two questions: what changed and why. We follow a rough convention for commit messages that is designed to answer two questions: what changed and why.
The subject line should feature the what and the body of the commit should describe the why. The subject line should feature the what and the body of the commit should describe the why.
``` ```git
scripts: add the test-cluster command scripts: add the test-cluster command
this uses tmux to setup a test cluster that you can easily kill and this uses tmux to setup a test cluster that you can easily kill and
@ -66,7 +68,7 @@ Fixes #38
The format can be described more formally as follows: The format can be described more formally as follows:
``` ```git
<subsystem>: <what changed> <subsystem>: <what changed>
<BLANK LINE> <BLANK LINE>
<why this change was made> <why this change was made>

14
README.md
View file

@ -57,10 +57,10 @@ For more information read [CONTRIBUTING.md].
In order to compile the project, the [latest stable version of Go] and knowledge of a [working Go environment] are required. In order to compile the project, the [latest stable version of Go] and knowledge of a [working Go environment] are required.
```sh ```sh
$ git clone git@github.com:chihaya/chihaya.git git clone git@github.com:chihaya/chihaya.git
$ cd chihaya cd chihaya
$ go build ./cmd/chihaya go build ./cmd/chihaya
$ ./chihaya --help ./chihaya --help
``` ```
[latest stable version of Go]: https://golang.org/dl [latest stable version of Go]: https://golang.org/dl
@ -79,15 +79,15 @@ The following will run all tests and benchmarks.
Removing `-bench` will just run unit tests. Removing `-bench` will just run unit tests.
```sh ```sh
$ go test -bench $(go list ./...) go test -bench $(go list ./...)
``` ```
The Chihaya executable contains a command to end-to-end test a BitTorrent tracker. The Chihaya executable contains a command to end-to-end test a BitTorrent tracker.
See See
```sh ```sh
$ chihaya --help chihaya --help
``` ```
### Configuration ### Configuration

6
docs/architecture.md
View file

@ -1,6 +1,6 @@
# Architecture # Architecture
### Overview ## Overview
BitTorrent clients send Announce and Scrape requests to a _Frontend_. BitTorrent clients send Announce and Scrape requests to a _Frontend_.
Frontends parse requests and write responses for the particular protocol they implement. Frontends parse requests and write responses for the particular protocol they implement.
@ -11,6 +11,6 @@ After all PreHooks have executed, any missing response fields that are required
PostHooks are asynchronous tasks that occur after a response has been delivered to the client. PostHooks are asynchronous tasks that occur after a response has been delivered to the client.
Because they are unnecessary to for generating a response, updates to the Storage for a particular request are done asynchronously in a PostHook. Because they are unnecessary to for generating a response, updates to the Storage for a particular request are done asynchronously in a PostHook.
### Diagram ## Diagram
![](https://user-images.githubusercontent.com/343539/52676700-05c45c80-2ef9-11e9-9887-8366008b4e7e.png) ![architecture diagram](https://user-images.githubusercontent.com/343539/52676700-05c45c80-2ef9-11e9-9887-8366008b4e7e.png)

22
docs/frontend.md
View file

@ -44,11 +44,11 @@ The typical control flow of handling announces, in more detail, is:
6. Send the response to the Client. 6. Send the response to the Client.
7. Pass the request and response to the `TrackerLogic`'s `AfterAnnounce` or `AfterScrape` method. 7. Pass the request and response to the `TrackerLogic`'s `AfterAnnounce` or `AfterScrape` method.
8. Finish, accept next request. 8. Finish, accept next request.
9. For invalid requests or errors during processing: Send an error response to the client. 9. For invalid requests or errors during processing: Send an error response to the client.
This step may be skipped for suspected denial-of-service attacks. This step may be skipped for suspected denial-of-service attacks.
The error response may contain information about the cause of the error. The error response may contain information about the cause of the error.
Only errors where the Client is at fault should be explained, internal server errors should be returned without explanation. Only errors where the Client is at fault should be explained, internal server errors should be returned without explanation.
Then finish, and accept the next request. Then finish, and accept the next request.
#### Configuration #### Configuration
@ -62,20 +62,22 @@ Frontends may provide runtime metrics, such as the number of requests or their d
Metrics must be reported using [Prometheus]. Metrics must be reported using [Prometheus].
A frontend should provide at least the following metrics: A frontend should provide at least the following metrics:
- The number of valid and invalid requests handled - The number of valid and invalid requests handled
- The average time it takes to handle a single request. - The average time it takes to handle a single request.
This request timing should be made optional using a config entry. This request timing should be made optional using a config entry.
Requests should be separated by type, i.e. Scrapes, Announces, and other protocol-specific requests. Requests should be separated by type, i.e. Scrapes, Announces, and other protocol-specific requests.
If the frontend serves multiple transports or networks, metrics for them should be separable. If the frontend serves multiple transports or networks, metrics for them should be separable.
It is recommended to publish one Prometheus `HistogramVec` with: It is recommended to publish one Prometheus `HistogramVec` with:
- A name like `chihaya_PROTOCOL_response_duration_milliseconds` - A name like `chihaya_PROTOCOL_response_duration_milliseconds`
- A value holding the duration in milliseconds of the reported request - A value holding the duration in milliseconds of the reported request
- Labels for: - Labels for:
- `action` (= `announce`, `scrape`, ...) - `action` (= `announce`, `scrape`, ...)
- `address_family` (= `Unknown`, `IPv4`, `IPv6`, ...), if applicable - `address_family` (= `Unknown`, `IPv4`, `IPv6`, ...), if applicable
- `error` (= A textual representation of the error encountered during processing.) - `error` (= A textual representation of the error encountered during processing.)
Because `error` is expected to hold the textual representation of any error that occurred during the request, great care must be taken to ensure all error messages are static. Because `error` is expected to hold the textual representation of any error that occurred during the request, great care must be taken to ensure all error messages are static.
`error` must not contain any information directly taken from the request, e.g. the value of an invalid parameter. `error` must not contain any information directly taken from the request, e.g. the value of an invalid parameter.
This would cause this dimension of prometheus to explode, which slows down prometheus clients and reporters. This would cause this dimension of prometheus to explode, which slows down prometheus clients and reporters.
@ -106,4 +108,4 @@ This way, a PreHook can communicate with a PostHook by setting a context value.
[BEP 3]: http://bittorrent.org/beps/bep_0003.html [BEP 3]: http://bittorrent.org/beps/bep_0003.html
[BEP 15]: http://bittorrent.org/beps/bep_0015.html [BEP 15]: http://bittorrent.org/beps/bep_0015.html
[Prometheus]: https://prometheus.io/ [Prometheus]: https://prometheus.io/
[old-opentracker-style]: https://web.archive.org/web/20170503181830/http://opentracker.blog.h3q.com/2007/12/28/the-ipv6-situation/ [old-opentracker-style]: https://web.archive.org/web/20170503181830/http://opentracker.blog.h3q.com/2007/12/28/the-ipv6-situation/

7
docs/storage/redis.md
View file

@ -59,7 +59,7 @@ All the InfoHashes (swarms) are also stored in a redis hash, with IP family as t
Here is an example: Here is an example:
``` ```yaml
- IPv4 - IPv4
- IPv4_S_<infohash 1>: <modification time> - IPv4_S_<infohash 1>: <modification time>
- IPv4_L_<infohash 1>: <modification time> - IPv4_L_<infohash 1>: <modification time>
@ -73,15 +73,14 @@ Here is an example:
- <peer 3 key>: <modification time> - <peer 3 key>: <modification time>
``` ```
In this case, prometheus would record two swarms, three seeders, and one leecher. In this case, prometheus would record two swarms, three seeders, and one leecher.
These three keys per address family are used to record the count of swarms, seeders, and leechers. These three keys per address family are used to record the count of swarms, seeders, and leechers.
``` ```yaml
- IPv4_infohash_count: 2 - IPv4_infohash_count: 2
- IPv4_S_count: 3 - IPv4_S_count: 3
- IPv4_L_count: 1 - IPv4_L_count: 1
``` ```
Note: IPv4_infohash_count has a different meaning compared to the `memory` storage: Note: `IPv4_infohash_count` has a different meaning compared to the `memory` storage:
It represents the number of infohashes reported by seeder, meaning that infohashes without seeders are not counted. It represents the number of infohashes reported by seeder, meaning that infohashes without seeders are not counted.