The function already has a parameter named `result`.
Also remove a duplicate variable since it already has a pref pointer at the start of the function.
PR #21571.
This help identifying threads when debugging.
The naming scheme is using 'class/function name + variable name'.
Note that the length limitaion is 16 chars on linux. On Windows, the limit is 32767 chars.
PR #21403.
1. Previously unhandled connections will stay in pending state. It won't
be closed until timeout happened. This may lead to wasting system
resources. Now the (over-limit) connection is actively rejected.
2. When out-of-memory occurs here, reject the new connection instead of
throwing exception and crash.
3. Also clean up some unused bits.
PR #20961.
The 'SSL torrent' feature is not standardized. I.e. there are no BEP (BitTorrent Enhancement Proposals) associated with it, so we do not greatly encourage its usage as it will only work with libtorrent clients and derivatives. It will not work with other torrent clients that do not support the libtorrent specific implementation.
This PR aims to provide minimal support for those who need SSL torrents. Furthermore, it is intended that there will be no UI support (nor indication) of adding/creating SSL torrents.
* Prerequisites:
I omit the instructions of creating those files as the intended audience (experts & advanced users) should have no problem with it. All files are as follow:
1. Root (torrent publisher) certificate
2. Root private key
3. A .torrent file created with root certificate
5. Peer certificate (signed by the root certificate)
6. Peer private key
7. Diffie-Hellman parameters file
All files are stored in .pem format.
* Enable SSL torrent protocol in qbt
There are 2 hidden keys to put in qbt config file, under `[BitTorrent]` section:
1. `Session\SSL\Enabled`: set it to `true`.
2. `Session\SSL\Port`: set it to some unused port or omit the key entirely to let qbt pick one for you.
* Add an SSL torrent to qbt
The only way of adding an SSL torrent is via WebAPI. The `/api/v2/torrents/add` endpoint will support 3 additional parameters. You must provide them for an SSL torrent.
1. `ssl_certificate`: Contents of the peer certificate file (in PEM format).
2. `ssl_private_key`: Contents of the peer private key file.
3. `ssl_dh_params`: Contents of the Diffie-Hellman parameters file.
* Change the SSL parameters to a torrent
In case you provided wrong SSL parameters when adding a torrent, there is a new endpoint `/api/v2/torrents/setSSLParameters` that you can update the SSL parameters. The parameters (`ssl_*`) are the same as `/api/v2/torrents/add` endpoint.
* Query the SSL parameters of a torrent
There is a new endpoint `/api/v2/torrents/SSLParameters` that you can query the SSL parameters of a torrent.
References:
* https://www.libtorrent.org/manual-ref.html#ssl-torrents
* https://blog.libtorrent.org/2012/01/bittorrent-over-ssl/
PR #20338.
---------
Co-authored-by: Radu Carpa <radu.carpa@cern.ch>
* Use compiler generated comparison function
* Use designated initializers
* Convert to proper type
* Use reference
* Remove redundant text
The `msg` already contain the text `Reason:` so it isn't needed.
PR #20312.
It now guards against reading infinite files such as `/dev/zero`.
And most readings are bound with a (lax) limit.
As a side effect, more checking are done when reading a file and
overall the reading procedure is more robust.
PR #19095.
PR #17814.
Closes#17792.
Closes#929.
(Actually it should close all issues about lack of ability to stop torrent after metadata downloaded or after files are initially checked.)
Also makes explicit the temporary start of the torrent in the case when recheck of the stopped torrent is performed.
Reduce the total startup time of the application and maintain sufficient responsiveness of the UI during startup due to the following:
1. Load resume data from disk asynchronously in separate thread;
2. Split handling of loaded resume data in chunks;
3. Reduce the number of emitting signals.
PR #16840.
Change "Incomplete/temp folder" term with "download folder".
Allow to set "download folder" per torrent (in manual mode) and per category (in automatic mode).
We can no longer save valid torrent files in the general case, because
for torrents of version 2, we need a full merkle tree to do it, but if
a torrent is added from magnet link, full merkle tree may not be available
even before the end of downloading all the data. Actually, we don't need
the full torrent file for the purposes of resuming the torrent, so we can
allow libtorrent to produce only a minimal part of the metadata as part
complete resume data, but we still want to store it in a separate file,
so we extract the resulting metadata from the complete resume data before
saving and merge it together before loading.
Both `lt::create_torrent` constructor and `lt::create_torrent::generate()`
can throw an exception so we need to handle it to prevent the app from crashing.
