1. 10 Aug, 2022 1 commit
  2. 03 Aug, 2022 1 commit
  3. 12 Jul, 2022 1 commit
  4. 14 Jun, 2022 3 commits
  5. 22 May, 2022 1 commit
  6. 12 Mar, 2022 1 commit
  7. 22 Jan, 2022 3 commits
  8. 20 Jan, 2022 1 commit
  9. 04 Dec, 2021 1 commit
    • Matt Whitlock's avatar
      mitigate potential DoS vector by limiting pending piece uploads · 327358a5
      Matt Whitlock authored and Andrius Štikonas's avatar Andrius Štikonas committed
      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.
      327358a5
  10. 08 Nov, 2021 1 commit
  11. 07 Oct, 2021 1 commit
  12. 26 Sep, 2021 13 commits
  13. 26 Aug, 2021 1 commit
  14. 19 Aug, 2021 1 commit
    • Matt Whitlock's avatar
      dht: expire announcement tokens after 30 minutes · 2b6b0d81
      Matt Whitlock authored
      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.
      2b6b0d81
  15. 15 Aug, 2021 2 commits
  16. 20 Jul, 2021 1 commit
  17. 18 Jul, 2021 1 commit
  18. 10 Jul, 2021 1 commit
  19. 26 Jun, 2021 2 commits
  20. 24 Jun, 2021 1 commit
    • Matt Whitlock's avatar
      respect file priority when selecting preview chunks · 852b0b4b
      Matt Whitlock authored
      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.
      852b0b4b
  21. 05 Jun, 2021 1 commit
  22. 18 May, 2021 1 commit