Matt Whitlock authored Nov 05, 2021 and Andrius Štikonas committed Dec 04, 2021

Previously there was no explicit limit on the number of piece requests
a peer could have outstanding. Each such request can potentially
consume memory up to the piece size of the torrent. Worse, since there
is no check for redundant requests, it was trivial for a peer to cause
us to consume unbounded amounts of memory by sending a long run of
requests for oversized pieces. (N.B.: Other implementations disconnect
peers for requesting more than 128 KiB at a time, but KTorrent allows
any requested size up to the piece size.)

This commit implements limits on the number of piece block uploads a
peer may have pending at any one time and on the total byte count of
those uploads. The limits are 512 uploads and 8 MiB of piece data. Any
requests received in excess of those limits are rejected. Note that
popular BitTorrent client implementations do not queue more than a
handful of piece requests at any one time, so these new limits are
expected to be proactively defensive only. That said, the author has
repeatedly observed KTorrent consuming over half a gigabyte of RAM in
queued PIECE messages waiting to be transmitted. The new limits are
intended to alleviate this pain.

Matt Whitlock authored Sep 06, 2021 and Andrius Štikonas committed Sep 26, 2021

KBucket::pingQuestionable(const KBucketEntry &) stashes its argument (the
prospective replacement KBucketEntry) in the KBucket::pending_entries
QList if the number of outstanding pings of questionable entries is 2 or
more. Unfortunately, the function was not checking for duplicate entries
in the pending_entries list, which was causing unbounded memory usage as
duplicate replacement entries would rapidly accumulate in the list.

This commit modifies the pingQuestionable function so that, before
inserting a replacement entry into the pending_entries list, it first
removes any matching entry from that list. Then, it *prepends* the new
entry to the list (rather than appending as it did before this commit)
since we want to consider the *freshest* replacements first when
endeavoring to replace bad entries. To bound memory usage, the list of
pending replacements is constrained to contain no more than K entries.

Seems like a copy-paste mistake from other license headers

dht::Database was exhibiting unbounded memory consumption due to
generating and remembering announcement tokens without ever expiring
and forgetting them. This commit augments the existing
dht::Database::expire(bt::Timestamp) function so that it erases tokens
that are more than MAX_ITEM_AGE (30 minutes) old. Also, it deletes and
erases DBItemList instances when they have been emptied by expirations.

Yaroslav Kurlaev authored Jul 20, 2021 and Andrius Štikonas committed Aug 15, 2021

* call start() after HTTPRequest creation
* connect replyFinished to QNetworkReply::finished instead of QNetworkAccessManager::finished

BUG: 404135

Yaroslav Kurlaev authored Jul 20, 2021 and Andrius Štikonas committed Aug 15, 2021

MiniUPnPd sends them like this and they are handled ok in other apps

Ömer Fadıl Usta authored Jun 26, 2021 and Friedrich W. H. Kossebau committed Jul 18, 2021

include_directories() does not take a target name, instead
cmake will get the include directories from the target when using
the target in the libraries link interfaces of other targets

GIT_SILENT

GIT_SILENT

GIT_SILENT

Previously, ChunkSelector would select preview chunks ahead of all
other chunks, regardless of file priority. This meant that files
prioritized as "Last" would nevertheless have all of their preview
chunks downloaded before all files prioritized as "First" or "Normal"
had finished downloading. This contradicts user expectation, which is
that scarce download bandwidth should not be devoted to files marked
"Last" until all files prioritized as "First" and "Normal" have been
completely downloaded.

This commit splits the existing PREVIEW_PRIORITY level into three
priority levels: FIRST_PREVIEW_PRIORITY, NORMAL_PREVIEW_PRIORITY, and
LAST_PREVIEW_PRIORITY. Chunks that ChunkManager determines to be
preview chunks have their priority levels boosted to the preview
priority level corresponding to their respective base priority level.

ChunkSelector's algorithm receives an overhaul that eliminates the
temporary std::list objects in favor of remembering the best (highest
priority, least number of downloaders) chunk during the iteration and
selecting that chunk if no chunk at the same priority level but with
no downloaders is found. The logic is ultimately equivalent to that
implemented in leastPeers(…) but will run faster since it requires no
heap allocations. Also, the new algorithm will not fail to select a
chunk that already has downloaders if there are no chunks that have no
downloaders. This should keep PieceDownloaders busier.