github.com/anacrolix/torrent@v1.61.0/internal/request-strategy/NOTES.md (about)

     1  Rough notes on how requests are determined.
     2  
     3  piece ordering cache:
     4  
     5  - pieces are grouped by shared storage capacity and ordered by priority, availability, index and then infohash.
     6  - if a torrent does not have a storage cap, pieces are also filtered by whether requests should currently be made for them. this is because for torrents without a storage cap, there's no need to consider pieces that won't be requested.
     7  
     8  building a list of candidate requests for a peer:
     9  
    10  - pieces are scanned in order of the pre-sorted order for the storage group.
    11  - scanning stops when the cumulative piece length so far exceeds the storage capacity.
    12  - pieces are filtered by whether requests should currently be made for them (hashing, marking, already complete, etc.)
    13  - if requests were added to the consideration list, or the piece was in a partial state, the piece length is added to a cumulative total of unverified bytes.
    14  - if the cumulative total of unverified bytes reaches the configured limit (default 64MiB), piece scanning is halted.
    15  
    16  applying request state:
    17  
    18  - send the appropriate interest message if our interest doesn't match what the peer is seeing
    19  - sort all candidate requests by:
    20    - allowed fast if we're being choked,
    21    - piece priority,
    22    - whether the request is already outstanding to the peer,
    23    - whether the request is not pending from any peer
    24    - if the request is outstanding from a peer:
    25      - how many outstanding requests the existing peer has
    26      - most recently requested
    27    - least available piece