Opened 3 years ago

#6147 new Enhancement

[patch] Custom piece priorities (private trackers only?)

Reported by: EyeTolledEweSew Owned by: jordan
Priority: Normal Milestone: None Set
Component: libtransmission Version: 2.92+
Severity: Normal Keywords:
Cc:

Description

Hi devs! I wrote a patch against 2.92 stable to allow individual piece priorities to be set by RPC.

My goal is to have a filesystem (or some equivalent) backed by Transmission: you add a torrent, "open" the resulting file, and "read" requests would be served by downloading the appropriate piece. The filesystem would prioritize piece requests according to the file seek position and/or content-aware tricks.

I'm aware that this opens that can of worms known as "sequential downloading". I agree with all the arguments (summarized here) that sequential downloading hurts public swarms, but I counter-argue that it doesn't hurt swarms on private trackers.

On all private trackers I know of, the rules are set up to incentivize uploading as much as possible. So peers never quit at a particular ratio, they only quit to free up disk space or bandwidth. So skewed piece demand wouldn't cause the "starvation" scenario described in the link above.

So I suggest custom piece priorities should be enabled only for torrents marked "private". Thoughts?

I tested this successfully on a public Big Buck Bunny torrent. I wrote a filesystem layer with Python (fusepy made this surprisingly easy) and was able to play it in a media player while downloading. I'm a member at a few private trackers, I'm still waiting on permission to test there. (I didn't enable the "private torrents only" check in the patch because for now I can only test on public swarms).

My patch is very preliminary, just to get conversation going. I tried to follow Transmission's philosophy of not building in the feature (RSS, labels, etc), but enabling the feature for anyone who cares to script/integrate enough.

Let me know if this patch should be broken into several.

Details of the patch:

  • The prioritization is implemented as the "piece-priority" field. For setting the field, I allow a "sparse list" input structure, e.g.:

piece-priority: {

indexes: [ 1, 5, 12 ], values: [ 1, 0, -1 ]

}

  • I added a "piece-max-requests-per-block" field for allowing individual pieces to enter a "endgame-like" state, and be requested from multiple peers. If a single piece is coming in slow and we'll need it soon, this is the most fine-grained way to "endgame" only the pieces we need. Can be set in the sparse list fashion above.
  • I added a "piece-get" bitfield, representing the "dnd" state of individual pieces. It can be set with "piece-wanted" or "piece-unwanted" fields.
  • I added a "pieces-on-disk" field for which pieces have been written to disk. The normal "pieces" field only showed what was in the cache, and the external program needs to know whether it can get a desired piece by reading the associated file on disk.
  • I added a "torrent-flush" RPC method to flush the torrent to disk.

Open issues with the patch:

  • I changed tr_priority_t to int32_t in transmission.h, and updated the appropriate structs. Will this break anything? Do any external projects depend on libtransmission?
  • How do we resolve file-level priorities vs. piece-level priorities? Right now file priorities may get overridden by piece priorities and this isn't reflected to the user.

Attachments (1)

priority.patch (28.3 KB) - added by EyeTolledEweSew 3 years ago.
Initial patch for custom piece priorities

Download all attachments as: .zip

Change History (1)

Changed 3 years ago by EyeTolledEweSew

Initial patch for custom piece priorities

Note: See TracTickets for help on using tickets.