Is it possible to track seeder/leecher ratio and or download/upload rates

[razorblade23]

In private mode /private_listed mode
Is it possible to track how much is the seeder/leecher uploaded data vs downloaded data or ratio?

I havent found this option in current version?
Is this been implemented?

[josecelano]

In private mode /private_listed mode Is it possible to track how much is the seeder/leecher uploaded data vs downloaded data or ratio?

I havent found this option in current version? Is this been implemented?

Hi @razorblade23 I guess you mean aggregate data for the peer. The tracker does not track that info for the time being. It only has the peer info for one torrent:

{
  "info_hash": "ec83837e5e828774d700dfa31636c40e89e079c3",
  "seeders": 2,
  "completed": 2,
  "leechers": 0,
  "peers": [
    {
      "peer_id": {
        "id": "0x2d6c74304438302dccc64dae7b46d41b64773e21",
        "client": "libTorrent (Rakshasa) / rTorrent"
      },
      "peer_addr": "XX.XX.XX.XX:63389",
      "updated": 1712080929009,
      "updated_milliseconds_ago": 1712080929009,
      "uploaded": 84881060,
      "downloaded": 84881060,
      "left": 0,
      "event": "None"
    },
    {
      "peer_id": {
        "id": "0x2d7142343339302d386162676d296e55216c4f68",
        "client": "qBittorrent"
      },
      "peer_addr": "YY.YY.YY.YY:64051",
      "updated": 1712081402011,
      "updated_milliseconds_ago": 1712081402011,
      "uploaded": 84881060,
      "downloaded": 0,
      "left": 0,
      "event": "None"
    }
  ]
}

You can open a feature request here.

FYI, we have been discussing the need for a proper logging system (or event sender/listener) to collect any metrics you want. But I think it's a feature we have to design carefully because users might have a lot of different needs. However what you are asking for it's a very common and useful feature.

cc @torrust/maintainers

[razorblade23]

Hy @josecelano
Glad to hear a fast response

Metrics for specific peers is more then welcome addition

Most off the private torrent sites use these metrics to give bonus points to users who has high seed ratio or to kick or limit the hit and runs (the ones that download but do not seed)

Its a valuable to have such information.
I hope you implent them as i love this tracker
Its easy to use and really fast (thanks to Rust)

[ERR1R]

would it be a good idea to build stuff like this like a injectable plugin? Then you keep the base like it is.

plugin bonus points

• calculating and distributing bonuspoints based on leech time/size. Older torrents get more bonuspoints etc..

plugin HNR

• using a HNR system.. Minimum seed requirement eg 5 days. If not seeding get a HNR (hit and run) and If downloaded more than 10% but not seeding, flag as HNR. etc..

plugin Leech bonus

• Share more than 1TiB (where a torrent count as max 50GiB) and you get site wide free leech

plugin free leech

• Make tracker free leech on any given moment

etc...

[josecelano]

Hi @ERR1R we like the idea of making the tracker extensible via plugins, but I have a lot of doubts about this approach. For example, would the plugins be injected and compile-time or runtime?

Alternatively, we could keep the tracker API simple. For example, we could have good events support. The tracker could trigger an event for every possible action and we could keep them in an event store. Indexes or other tracker's clients could pull events from the tracker API (or via other ways like subscriptions, ...). The clients would be responsible for building their data. The main event could be "peer announced". We could even split the event into more concrete events like: "peer started", "peer complete", ...

One solution in the middle could be just adding basic aggregate data for peers and let clients define their own rules (points).

Basic statistics for peers

TODO: define what good statistics per peer are.

Pros:

• Simple solution

Cons:

• ?

Plugins

Pros:

• ?

Cons:

• ?

Plugins at compile-time

Pros:

• Better performance and security.
• Plugins can be type-checked and verified at compile-time.

Cons:

• Users need to write plugins in Rust.
• Requires recompilation of the application whenever a new plugin is added or modified.

Plugins at runtime

Pros:

• Flexibility for users to write plugins in different languages.
• No need to recompile the application when adding or modifying plugins.

Cons:

• Lower performance due to dynamic loading and runtime overhead.
• Increased complexity in managing dynamic libraries and inter-language interoperability.

Links crates:

• https://docs.rs/dylib/latest/dylib/
• https://docs.rs/libloading/latest/libloading/

Link examples:

• https://lapce.dev/ (WASI plugin system)

Events

Pros:

• Tracker code would be stable and fast.

Cons:

• Users can not share plugins. They have to reimplement the same features again and again.

cc @torrust/maintainers

[razorblade23]

@josecelano

I think that it would be best to implement a "middle tier" solution you proposed

That way you can keep API simple, but also allow clients to agregate data and define HNR rules by themself

Extension by plugins is also a great idea, but the implementation could be troublesome

Plugins could be loaded at runtime but limited to a single language (at least for start) like maybe Python for simplicity

[josecelano]

@josecelano

I think that it would be best to implement a "middle tier" solution you proposed

That way you can keep API simple, but also allow clients to agregate data and define HNR rules by themself

Extension by plugins is also a great idea, but the implementation could be troublesome

Plugins could be loaded at runtime but limited to a single language (at least for start) like maybe Python for simplicity

@razorblade23 I think it could be implemented progressively:

1. Collect basic peer statistics and expose them via API endpoint.
2. Trigger events, collect them, and allow clients to consume those events. This could be an optional feature. It would allow clients to build any aggregate data they want. With option 1, there will be data they can not get anyway.
3. Implement a plug-in system at runtime and build plug-ins for specific very common policies.

[razorblade23]

@josecelano

Good plan, i like that

I would love to help out, but i am just learning Rust 😕