You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- 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
This directory contains integration style tests that probably run too long for regular unit testing. It's a separate module to avoid getting run by ./... in the root.
0 commit comments