v0.99.108

General

• The engine will now make EngineSettings.MaxPendingConnections simultaneous connections instead of EngineSettings.MaxPendingConnections - 1.
• Ensured that downloading torrents using a MagnetLink always does a Local Peer, DHT and Tracker announce to find the initial set of peers to retrieve the torrent metadata from. Previously it may have skipped the Tracker.
• Some behind the scenes work in the tests to make them run in approximately 2.5 seconds instead of 11.

v0.99.85

General

• Improvements to LocalPeerDiscovery
• Lots of internal refactoring which allowed for more thorough tests to be added for the encryption code, piece writing and piece picking.

v0.99.64

General

• Releases are now built using the deterministic compilation flag. This means it should be possible to independently compile bit-identical copies of the releases.
• Added code comments to a few more properties/types.
• Added a new public event, TorrentManager.ConnectionAttemptFailed. This provides some metadata to maybe explain why a particular connection attempt may have failed.
• Improved the fallbacks when attempting to connect to remote peers. If the connection is dropped while using a plain-text connection, a connection attempt will be automatically retried using an RC4 encrypted connection, if it's supported.
• Optimised TorrentManager.StopAsync so it can complete a little faster under normal conditions.
• Changed the semantics of TorrentManager.StartAsync and TorrentManager.StopAsync to make them more user friendly. StartAsync completes as soon as the TorrentManager enters any active mode (for example Downloading, Hashing, Metadata etc). StopAsync is marked as complete as soon as all the async tasks have completed and the torrent has fully stopped.
• Integrated a patch from @skelder to address an issue adding peers to private torrents (PR #119 )]
• When downloading a private torrent all PeerExchange messages are ignored as only peers received from a Tracker are allowed. Optimise this scenario by excluding PeerExchange support from the list of supported features when sending the handshake message.

v0.99.40

General

• Some API breaking renames in the MonoTorrent.Tracker namespace:
  Tracker -> TrackerServer
  ScrapeParameters -> ScrapeRequest
  AnnounceParameters -> AnnounceRequest
  RequestParameters -> TrackerRequest
• Made ClientAddressComparer and PeerIdComparer public so they can be easily used when instantiating a TrackerServer.
• Fixed an issue in the TrackerServer implementation where the InfoHash in the files dictionary was hex encoded instead of BEncoded when responding to a HTTP scrape request.
• Added sanity checks to the client side HttpTracker logic to ensure that the scrape response contains the expected InfoHash as a 20 byte BEncodedString.
• Added code comments to a bunch of properties/methods.

v0.99.27

General

No real changes, just removing some blocking .Result and .Wait calls and move to normal async/await where possible.

v0.99.22

General

• Added additional tests and fixed a few more cases where identifiers consisting of arbitrary bytes were being respresented as a string instead of a BEncodedString.
• Fixed a bug where UDP trackers were non-functional because the connection id was being double encoded in network byte order.
• Fixed some more edge cases when swapping between a single announce and tracker tiers when editing torrents.

v0.99.10

General

• Added the ability to incremental hash pieces as they are downloaded.
• Added the ability to null out string based properties when using TorrentEditor.

v0.99.8

General

Small change to ensure that PeerIds, TrackerIds and tracker Keys are always represented as a BEncodedString. They can be arbitrary bytes so don't assume they can be represented in any text encoding.

v0.99.4

General

Fixed a regression requesting pieces using the fast peer extensions. The first block of the piece was not being downloaded immediately.

v0.99.2

General

A few fixes around how the 'peer id', 'key' and 'tracker id' parameters are generated and sent to/from trackers. Where possible all arbitrary keys/identifiers are generated using the same scheme as the peer id, something like: MO1234-<random_data> where MO is for MonoTorrent, and 1234 is for the version 1.2.3.4.