To acquire the latest version of libtorrent, you'll have to grab it from SVN.
-You'll find instructions on how to do this here (see subversion access).
+You'll find instructions on how to do this here (see subversion access).
The build systems supported "out of the box" in libtorrent are boost-build v2
(BBv2) and autotools (for unix-like systems). If you still can't build after
following these instructions, you can usually get help in the #libtorrent
IRC channel on irc.freenode.net.
-
Community contributed build tutorials can be found on the wiki.
+
Community contributed build tutorials can be found on the wiki.
building from svn
To build libtorrent from svn you need to check out the libtorrent sources from
@@ -69,8 +71,8 @@ sourceforge and also check out the asio sources from its sourceforge cvs.
If you downloaded a release tarball, you can skip this section.
To prepare the directory structure for building, follow these steps:
Copy the asio/include/asio/ directory into the libtorrent/include/libtorrent/
directory. Alternatively you can make a symbolic link.
Copy asio/include/asio.hpp into libtorrent/include/libtorrent.
@@ -82,7 +84,7 @@ of the following sections depending on which build system you prefer to use.
building with BBv2
The primary reason to use boost-build is that it will automatically build the
dependent boost libraries with the correct compiler settings, in order to
-ensure that the build targets are link compatible (see boost guidelines
+ensure that the build targets are link compatible (see boost guidelines
for some details on this issue).
Since BBv2 will build the boost libraries for you, you need the full boost
source package. Having boost installed via some package system is usually not
@@ -92,7 +94,7 @@ usually not set by the package installer).
to step 3 (assuming you also have boost build installed).
Extract the archive to some directory where you want it. For the sake of this
guide, let's assume you extract the package to c:\boost_1_34_0 (I'm using
a windows path in this example since if you're on linux/unix you're more likely
@@ -150,7 +152,7 @@ using darwin : 3.3 : g++-3.3 ;
using darwin : 4.0 : g++-4.0 ;
Note that the spaces around the semi-colons and colons are important!
@@ -202,6 +204,11 @@ the POSIX clock functions. If you get an error complaining about a missing
symbol clock_gettime, you have to give need-librt=yes on the
bjam command line. This will make libtorrent link against librt.
+
+
Note
+
When building on Solaris, you might have to specify stdlib=sun-stlport
+on the bjam command line.
+
The build targets are put in a directory called bin, and under it they are
sorted in directories depending on the toolset and build variant used.
To build the examples, just change directory to the examples directory and
@@ -215,7 +222,7 @@ Also, make sure the paths are correct in the different environments. In cygwin,
/cygdrive/c/boost_1_34_0). In the windows environment, they should have the typical
windows format (c:/boost_1_34_0).
The Jamfile will define NDEBUG when it's building a release build.
-For more build configuration flags see Build configurations.
shared - The MaxMind geo ip lookup library
is expected to be installed on the system and
it will be used.
@@ -415,8 +422,8 @@ the name of the feature, just the value.
When building the example client on windows, you need to build with
link=static otherwise you may get unresolved external symbols for some
boost.program-options symbols.
No build system is present if libtorrent is checked out from CVS - it
needs to be generated first. If you're building from a released tarball,
-you may skip directly to Step 2: Running configure.
Execute the following commands, in the given order, to generate
the build system:
@@ -544,7 +551,7 @@ filenames, so if your target is Windows 2000 and up, you may want to use
If you're building in MS Visual Studio, you may have to set the compiler
options "force conformance in for loop scope", "treat wchar_t as built-in
type" and "Enable Run-Time Type Info" to Yes. For a detailed description
-on how to build libtorrent with VS, see the wiki.
+on how to build libtorrent with VS, see the wiki.
libtorrent is a C++ library that aims to be a good alternative to all the
-other bittorrent implementations around. It is a
-library and not a full featured client, although it comes with a working
-example client.
-
The main goals of libtorrent are:
-
-
to be cpu efficient
-
to be memory efficient
-
to be very easy to use
-
+
libtorrent is a feature complete C++ bittorrent implementation focusing
+on efficiency and scalability. It runs on embedded devices as well as
+desktops. It boasts a well documented library interface that is easy to
+use. It comes with a simple bittorrent client demonstrating the use of
+the library.
features
-
libtorrent is still being developed, however it is stable. It is an ongoing
-project (including this documentation). The current state includes the
-following features:
+
libtorrent is under active development. It is an ongoing project. Its
+current state supports and includes the following features:
+
+
extensions
-
trackerless torrents (using the Mainline kademlia DHT protocol) with
-some DHT extensions. BEP 5.
uses a separate disk I/O thread to not have the disk ever block on network or
+client interaction. (see threads).
supports files > 2 gigabytes.
-
serves multiple torrents on a single port and in a single thread
fast resume support, a way to get rid of the costly piece check at the
start of a resumed torrent. Saves the storage state, piece_picker state
as well as all local peers in a separate fast-resume file.
has an adjustable read and write disk cache for improved disk throughput.
+
queues torrents for file check, instead of checking all of them in parallel.
+
does not have any requirements on the piece order in a torrent that it
+resumes. This means it can resume a torrent downloaded by any client.
+
supports both sparse files and compact file allocation (where pieces
+are kept consolidated on disk)
+
seed mode, where the files on disk are assumed to be complete, and each
+piece's hash is verified the first time it is requested.
+
+
+
+
network
+
+
adjusts the length of the request queue depending on download rate.
+
serves multiple torrents on a single port and in a single thread
piece picking on block-level (as opposed to piece-level).
This means it can download parts of the same piece from different peers.
It will also prefer to download whole pieces from single peers if the
download speed is high enough from that particular peer.
queues torrents for file check, instead of checking all of them in parallel.
supports http proxies and basic proxy authentication
-
gzipped tracker-responses
+
supports gzipped tracker-responses
can limit the upload and download bandwidth usage and the maximum number of
unchoked peers
implements fair trade. User settable trade-ratio, must at least be 1:1,
but one can choose to trade 1 for 2 or any other ratio that isn't unfair
to the other party.
-
supports the no_peer_id=1 extension that will ease the load off trackers.
possibility to limit the number of connections.
delays have messages if there's no other outgoing traffic to the peer, and
doesn't send have messages to peers that already has the piece. This saves
bandwidth.
-
does not have any requirements on the piece order in a torrent that it
-resumes. This means it can resume a torrent downloaded by any client.
-
supports the compact=1 tracker parameter.
selective downloading. The ability to select which parts of a torrent you
want to download.
ip filter to disallow ip addresses and ip ranges from connecting and
being connected
NAT-PMP and UPnP support (automatic port mapping on routers that supports it)
+
+
+
highlighted features
+
+
disk caching
+
All disk I/O in libtorrent is done asynchronously to the network thread, by the
+disk io thread. When a block is read, the disk io thread reads all subsequent
+blocks from that piece into the read cache, assuming that the peer requesting
+the block will also request more blocks from the same piece. This decreases the
+number of syscalls for reading data. It also decreases delay from seeking.
+
Similarly, for write requests, blocks are cached and flushed to disk once one full
+piece is complete or the piece is the least recently updated one when more cache
+space is needed. The cache dynamically allocates space between the write and read
+cache. The write cache is strictly prioritized over the read cache.
+
The cache blocks that are in used, are locked into physical memory to avoid it
+being paged out to disk. Allowing the disk cache to be paged out to disk means
+that it would become extremely inefficient to flush it, since it would have to be
+read back into physical memory only to be flushed back out to disk again.
+
In order to conserve memory, and system calls, iovec file operations are
+used to flush multiple cache blocks in a single call.
+
On low-memory systems, the disk cache can be disabled altogether or set to smaller
+limit, to save memory.
+
+
+
network buffers
+
On CPUs with small L2 caches, copying memory can be expensive operations. It is important
+to keep copying to a minimum on such machines. This mostly applies to embedded systems.
+
In order to minimize the number of times received data is copied, the receive buffer
+for payload data is received directly into a page aligned disk buffer. If the connection
+is encrypted, the buffer is decrypted in-place. The buffer is then moved into the disk
+cache without being copied. Once all the blocks for a piece have been received, or the
+cache needs to be flushed, all the blocks are passed directly to writev() to flush
+them in a single syscall. This means a single copy into user space memory, and a single
+copy back into kernel memory, as illustrated by this figure:
+
+
When seeding and uploading in general, unnecessary copying is avoided by caching blocks
+in aligned buffers, that are copied once into the peer's send buffer. The peer's send buffer
+is not guaranteed to be aligned, even though it is most of the time. The send buffer is
+then encrypted with the peer specific key and chained onto the iovec for sending.
+This means there is one user space copy in order to allow unaligned peer requests and
+peer-specific encryption. This is illustrated by the following figure:
+
+
+
+
piece picker
+
The piece picker is a central component in a bittorrent implementation. The piece picker
+in libtorrent is optimized for quickly finding the rarest pieces. It keeps a list of all
+available pieces sorted by rarity, and pieces with the same rarity, shuffled. The rarest
+first mode is the dominant piece picker mode. Other modes are supported as well, and
+used by peers in specific situations.
+
The piece picker allows to combine the availability of a piece with a priority. Together
+they determine the sort order of the piece list. Pieces with priority 0 will never be
+picked, which is used for the selective download feature.
+
In order to have as few partially finished pieces as possible, peers have an affinity
+towards picking blocks from the same pieces as other peers in the same speed category.
+The speed category is a coarse categorization of peers based on their download rate. This
+makes slow peers pick blocks from the same piece, and fast peers pick from the same piece,
+and hence decreasing the likelihood of slow peers blocking the completion of pieces.
+
The piece picker can also be set to download pieces in sequential order.
+
+
portability
-
libtorrent is portable at least among Windows, MacOS X and other UNIX-systems.
+
libtorrent runs on most major operating systems, including Windows,
+MacOS X, Linux, BSD and Solaris.
It uses Boost.Thread, Boost.Filesystem, Boost.Date_time and various other
-boost libraries as well as zlib (shipped) and asio (shipped). At least version
+boost libraries as well as zlib (shipped) and asio (shipped). At least version
1.34.1 of boost is required.
-
Since libtorrent uses asio, it will take full advantage of high performance
+
libtorrent uses asio, hence it will take full advantage of high performance
network APIs on the most popular platforms. I/O completion ports on windows,
epoll on linux and kqueue on MacOS X and BSD.
libtorrent has been successfully compiled and tested on:
-
Windows 2000 vc7.1, vc8
-
Linux x86 GCC 3.3, GCC 3.4.2
+
Windows 2000, XP and Vista vc7.1, vc8
+
Linux x86 GCC 3.3, GCC 3.4.2, 4.x
+
Linux PPC GCC 4.1.1
MacOS X (darwin), (Apple's) GCC 3.3, (Apple's) GCC 4.0
-
SunOS 5.8 GCC 3.1
+
SunOS 5.8 GCC 3.1 and Sunpro
Cygwin GCC 3.3.3
Fails on:
@@ -142,15 +227,6 @@ epoll on linux and kqueue on MacOS X and BSD.
This means that you can use the library in your project without having to
-release its source code. The only requirement is that you give credit
-to the author of the library by including the libtorrent license in your
-software or documentation.
-
Here's a list of some projects that uses libtorrent.
diff --git a/docs/index.rst b/docs/index.rst
index e54fffdd0..a0d55fdc8 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -73,10 +73,11 @@ libtorrent
.. _`Introduction, slides`: bittorrent.pdf
-libtorrent is a C++ library that aims to be a good alternative to all the
-other bittorrent implementations around. It is a
-library and not a full featured client, although it comes with a working
-`example client`__.
+libtorrent is a feature complete C++ bittorrent implementation focusing
+on efficiency and scalability. It runs on embedded devices as well as
+desktops. It boasts a well documented library interface that is easy to
+use. It comes with a `simple bittorrent client`__ demonstrating the use of
+the library.
__ client_test.html
@@ -116,23 +117,46 @@ __ http://lists.sourceforge.net/lists/listinfo/libtorrent-discuss
You can usually find me as hydri in ``#libtorrent`` on ``irc.freenode.net``.
+license
+=======
+
+libtorrent is released under the BSD-license_.
+
+.. _BSD-license: http://www.opensource.org/licenses/bsd-license.php
+
+This means that you can use the library in your project without having to
+release its source code. The only requirement is that you give credit
+to the author of the library by including the libtorrent license in your
+software or documentation.
+
+It is however greatly appreciated if additional features are contributed
+back to the open source project. Patches can be emailed to the mailing
+list or posted to the `bug tracker`_.
+
+.. _`bug tracker`: http://code.rasterbar.com/libtorrent/newticket
Acknowledgements
================
-Written by Arvid Norberg. Copyright (c) 2003-2006
+Written by Arvid Norberg. Copyright |copy| 2003-2009
Contributions by Magnus Jonsson, Daniel Wallin and Cory Nelson
Thanks to Reimond Retz for bugfixes, suggestions and testing
+Thanks to `Umeå University`__ for providing development and test hardware.
+
+__ http://www.cs.umu.se
+
Project is hosted by sourceforge.
|sf_logo|__
-.. |sf_logo| image:: http://sourceforge.net/sflogo.php?group_id=7994
__ http://sourceforge.net
+.. |sf_logo| image:: http://sourceforge.net/sflogo.php?group_id=7994
+.. |copy| unicode:: 0xA9 .. copyright sign
+
.. raw:: html
If the fingerprint in the first overload is omited, the client will get a default
fingerprint stating the version of libtorrent. The fingerprint is a short string that will be
used in the peer-id to identify the client and the client's version. For more details see the
-fingerprint class. The constructor that only takes a fingerprint will not open a
+fingerprint class. The constructor that only takes a fingerprint will not open a
listen port for the session, to get it running you'll have to call session::listen_on().
The other constructor, that takes a port range and an interface as well as the fingerprint
will automatically try to listen on a port on the given interface. For more information about
@@ -461,7 +466,7 @@ the parameters, see listen_on()The flags paramater can be used to start default features (upnp & nat-pmp) and default plugins
(ut_metadata, ut_pex and smart_ban). The default is to start those things. If you do not want
them to start, pass 0 as the flags parameter.
-
The alert_mask is the same mask that you would send to set_alert_mask().
+
The alert_mask is the same mask that you would send to set_alert_mask().
Pausing the session has the same effect as pausing every torrent in it. Resuming
-will restore the torrents to their previous paused state. i.e. the session pause
-state is separate from the torrent pause state. A torrent is inactive if it is
-paused or if the session is paused.
+
Pausing the session has the same effect as pausing every torrent in it, except that
+torrents will not be resumed by the auto-manage mechanism. Resuming will restore the
+torrents to their previous paused state. i.e. the session pause state is separate from
+the torrent pause state. A torrent is inactive if it is paused or if the session is
+paused.
abort()
@@ -533,6 +539,7 @@ struct add_torrent_params
bool duplicate_is_error;
storage_constructor_type storage;
void* userdata;
+ bool seed_mode;
};
torrent_handle add_torrent(add_torrent_params const& params);
@@ -554,12 +561,12 @@ the torrent as long as it doesn't have metadata. See add_torrent() will throw
-duplicate_torrent which derives from std::exception unless duplicate_is_error
+duplicate_torrent which derives from std::exception unless duplicate_is_error
is set to false. In that case, add_torrent will return the handle to the existing
torrent.
The optional parameter, resume_data can be given if up to date fast-resume data
is available. The fast-resume data can be acquired from a running torrent by calling
-save_resume_data() on torrent_handle. See fast resume. The vector that is
+save_resume_data() on torrent_handle. See fast resume. The vector that is
passed in will be swapped into the running torrent instance with std::vector::swap().
The storage_mode parameter refers to the layout of the storage for this torrent.
There are 3 different modes:
@@ -579,7 +586,7 @@ with zeroes.
are rearranged to finally be in their correct places once the entire torrent has been
downloaded.
-
paused is a boolean that specifies whether or not the torrent is to be started in
a paused state. I.e. it won't connect to the tracker or any of the peers until it's
resumed. This is typically a good way of avoiding race conditions when setting
@@ -587,15 +594,24 @@ configuration options on torrents before starting them.
If auto_managed is true, this torrent will be queued, started and seeded
automatically by libtorrent. When this is set, the torrent should also be started
as paused. The default queue order is the order the torrents were added. They
-are all downloaded in that order. For more details, see queuing.
+are all downloaded in that order. For more details, see queuing.
storage can be used to customize how the data is stored. The default
storage will simply write the data to the files it belongs to, but it could be
overridden to save everything to a single file at a specific location or encrypt the
content on disk for instance. For more information about the storage_interface
-that needs to be implemented for a custom storage, see storage_interface.
+that needs to be implemented for a custom storage, see storage_interface.
The userdata parameter is optional and will be passed on to the extension
-constructor functions, if any (see add_extension()).
-
The torrent_handle returned by add_torrent() can be used to retrieve information
+constructor functions, if any (see add_extension()).
+
If seed_mode is set to true, libtorrent will assume that all files are present
+for this torrent and that they all match the hashes in the torrent file. Each time
+a peer requests to download a block, the piece is verified against the hash, unless
+it has been verified already. If a hash fails, the torrent will automatically leave
+the seed mode and recheck all the files. The use case for this mode is if a torrent
+is created and seeded, or if the user already know that the files are complete, this
+is a way to avoid the initial file checks, and significantly reduce the startup time.
+
Setting seed_mode on a torrent without metadata (a .torrent file) is a no-op
+and will be ignored.
+
The torrent_handle returned by add_torrent() can be used to retrieve information
about the torrent's progress, its peers etc. It is also used to abort a torrent.
@@ -610,7 +626,7 @@ the tracker that we've stopped participating in the swarm. The optional second a
options can be used to delete all the files downloaded by this torrent. To do this, pass
in the value session::delete_files. The removal of the torrent is asyncronous, there is
no guarantee that adding the same torrent immediately after it was removed will not throw
-a duplicate_torrent exception.
+a duplicate_torrent exception.
find_torrent() get_torrents()
@@ -704,7 +720,7 @@ int as_for_ip(address const& adr);
Sets a filter that will be used to reject and accept incoming as well as outgoing
connections based on their originating ip address. The default filter will allow
connections to any ip address. To build a set of rules for which addresses are
-accepted and not, see ip_filter.
-
Each time a peer is blocked because of the IP filter, a peer_blocked_alert is
+accepted and not, see ip_filter.
+
Each time a peer is blocked because of the IP filter, a peer_blocked_alert is
generated.
@@ -940,7 +956,7 @@ the range and so on. The interface parameter can be left as 0, in that case the
os will decide which interface to listen on, otherwise it should be the ip-address
of the interface you want the listener socket bound to. listen_on() returns true
if it managed to open the socket, and false if it failed. If it fails, it will also
-generate an appropriate alert (listen_failed_alert).
+generate an appropriate alert (listen_failed_alert).
The interface parameter can also be a hostname that will resolve to the device you
want to listen on.
If you're also starting the DHT, it is a good idea to do that after you've called
@@ -968,7 +984,7 @@ void set_alert_mask(int m);
Changes the mask of which alerts to receive. By default only errors are reported.
m is a bitmask where each bit represents a category of alerts.
-
See alerts for mor information on the alert categories.
+
See alerts for mor information on the alert categories.
pop_alert() is used to ask the session if any errors or events has occurred. With
-set_alert_mask() you can filter which alerts to receive through pop_alert().
-For information about the alert categories, see alerts.
+set_alert_mask() you can filter which alerts to receive through pop_alert().
+For information about the alert categories, see alerts.
wait_for_alert blocks until an alert is available, or for no more than max_wait
time. If wait_for_alert returns because of the time-out, and no alerts are available,
it returns 0. If at least one alert was generated, a pointer to that alert is returned.
@@ -1004,7 +1020,7 @@ void add_extension(boost::function<
This function adds an extension to this session. The argument is a function
object that is called with a torrent* and which should return a
boost::shared_ptr<torrent_plugin>. To write custom plugins, see
-libtorrent plugins. For the typical bittorrent client all of these
+libtorrent plugins. For the typical bittorrent client all of these
extensions should be added. The main plugins implemented in libtorrent are:
Sets the session settings and the packet encryption settings respectively.
-See session_settings and pe_settings for more information on available
+See session_settings and pe_settings for more information on available
options.
@@ -1069,13 +1085,13 @@ void set_dht_proxy(proxy_settings const& s);
sets the proxy settings for different kinds of connections, bittorrent peers,
web seeds, trackers and the DHT traffic.
set_peer_proxy affects regular bittorrent peers. set_web_seed_proxy
-affects only web seeds. see HTTP seeding.
@@ -1195,8 +1211,8 @@ void stop_upnp();
port are attempted to be forwarded on local UPnP router devices.
The upnp object returned by start_upnp() can be used to add and remove
arbitrary port mappings. Mapping status is returned through the
-portmap_alert and the portmap_error_alert. The object will be valid until
-stop_upnp() is called. See UPnP and NAT-PMP.
@@ -1211,8 +1227,8 @@ void stop_natpmp();
port are attempted to be forwarded on the router through NAT-PMP.
The natpmp object returned by start_natpmp() can be used to add and remove
arbitrary port mappings. Mapping status is returned through the
-portmap_alert and the portmap_error_alert. The object will be valid until
-stop_natpmp() is called. See UPnP and NAT-PMP.
The integer(), string(), list() and dict() functions
are accessors that return the respective type. If the entry object isn't of the
-type you request, the accessor will throw type_error (which derives from
+type you request, the accessor will throw type_error (which derives from
std::runtime_error). You can ask an entry for its type through the
type() function.
The print() function is there for debug purposes only.
@@ -1330,7 +1346,7 @@ if (entry* i = torrent_file.find_key("announce"))
std::cout << tracker_url << "\n";
}
-
To make it easier to extract information from a torrent file, the class torrent_info
+
To make it easier to extract information from a torrent file, the class torrent_info
exists.
@@ -1371,7 +1387,7 @@ key is found, the return a pointer to it.
torrent_info
In previous versions of libtorrent, this class was also used for creating
torrent files. This functionality has been moved to create_torrent, see
-make_torrent.
class torrent_info
@@ -1456,7 +1472,7 @@ from the swarm.
The constructor that takes a lazy_entry will create a torrent_info object from the
information found in the given torrent_file. The lazy_entry represents a tree node in
an bencoded file. To load an ordinary .torrent file
-into a lazy_entry, use lazy_bdecode(), see bdecode() bencode().
The version that takes a buffer pointer and a size will decode it as a .torrent file and
initialize the torrent_info object for you.
The version that takes a filename will simply load the torrent file and decode it inside
@@ -1471,7 +1487,7 @@ void add_tracker(std::string const& url, int tier = 0);
add_tracker() adds a tracker to the announce-list. The tier determines the order in
-which the trackers are to be tried. For more information see trackers().
+which the trackers are to be tried. For more information see trackers().
files() orig_files()
@@ -1615,7 +1631,7 @@ and http_seeds() will
add_url_seed() and add_http_seed() adds one url to the list of
url/http seeds. Currently, the only transport protocol
supported for the url is http.
-
@@ -1694,7 +1710,7 @@ char const* hash_for_piece_ptr(unsigned int index) const;
hash_for_piece() takes a piece-index and returns the 20-bytes sha1-hash for that
piece and info_hash() returns the 20-bytes sha1-hash for the info-section of the
-torrent file. For more information on the sha1_hash, see the big_number class.
+torrent file. For more information on the sha1_hash, see the big_number class.
hash_for_piece_ptr() returns a pointer to the 20 byte sha1 digest for the piece.
Note that the string is not null-terminated.
comment() returns the comment associated with the torrent. If there's no comment,
-it will return an empty string. creation_date() returns a boost::posix_time::ptime
+it will return an empty string. creation_date() returns a boost::posix_time::ptime
object, representing the time when this torrent file was created. If there's no time stamp
in the torrent file, this will return a date of January 1:st 1970.
Both the name and the comment is UTF-8 encoded strings.
@@ -1873,7 +1889,7 @@ valid handle. If you try to perform any operation on an uninitialized handle,
it will throw invalid_handle.
Warning
-
All operations on a torrent_handle may throw invalid_handle
+
All operations on a torrent_handle may throw invalid_handle
exception, in case the handle is no longer refering to a torrent. There is
one exception is_valid() will never throw.
Since the torrents are processed by a background thread, there is no
@@ -1950,7 +1966,7 @@ void file_progress(std::vector<size_type>& fp);
This function fills in the supplied vector with the the number of bytes downloaded
of each file in this torrent. The progress values are ordered the same as the files
-in the torrent_info. This operation is not very cheap. Its complexity is O(n + mj).
+in the torrent_info. This operation is not very cheap. Its complexity is O(n + mj).
Where n is the number of files, m is the number of downloading pieces and j
is the number of blocks in a piece.
@@ -1961,7 +1977,7 @@ is the number of blocks in a piece.
boost::filesystem::path save_path() const;
-
save_path() returns the path that was given to add_torrent() when this torrent
+
save_path() returns the path that was given to add_torrent() when this torrent
was started.
@@ -2044,8 +2060,8 @@ void read_piece(int piece) const;
this torrent. You must have completed the download of the specified piece before
calling this function.
When the read operation is completed, it is passed back through an alert,
-read_piece_alert. In order to receive this alert, you must enable
-alert::storage_notification in your alert mask (see set_alert_mask()).
+read_piece_alert. In order to receive this alert, you must enable
+alert::storage_notification in your alert mask (see set_alert_mask()).
Note that if you read multiple pieces, the read operations are not guaranteed to
finish in the same order as you initiated them.
@@ -2072,8 +2088,8 @@ void scrape_tracker() const;
tracker for statistics such as total number of incomplete peers, complete peers, number of
downloads etc.
This request will specifically update the num_complete and num_incomplete fields in
-the torrent_status struct once it completes. When it completes, it will generate a
-scrape_reply_alert. If it fails, it will generate a scrape_failed_alert.
@@ -2086,8 +2102,8 @@ void connect_peer(asio::ip::tcp::endpoint const& adr, int source = 0) const;
torrent. If the peer does not respond, or is not a member of this torrent, it will simply
be disconnected. No harm can be done by using this other than an unnecessary connection
attempt is made. If the torrent is uninitialized or in queued or checking mode, this
-will throw invalid_handle. The second (optional) argument will be bitwised ORed into
-the source mask of this peer. Typically this is one of the source flags in peer_info.
+will throw invalid_handle. The second (optional) argument will be bitwised ORed into
+the source mask of this peer. Typically this is one of the source flags in peer_info.
i.e. tracker, pex, dht etc.
@@ -2174,7 +2190,10 @@ bool is_paused() const;
When a torrent is paused, it will however remember all share ratios to all peers and remember
all potential (not connected) peers. You can use is_paused() to determine if a torrent
is currently paused. Torrents may be paused automatically if there is a file error (e.g. disk full)
-or something similar. See file_error_alert.
+or something similar. See file_error_alert.
+
torrents that are auto-managed may be automatically resumed again. It does not make sense to
+pause an auto-managed torrent without making it not automanaged first. Torrents are auto-managed
+by default when added to the session. For more information, see queuing.
is_paused() only returns true if the torrent itself is paused. If the torrent
is not running because the session is paused, this still returns false. To know if a
torrent is active or not, you need to inspect both torrent_handle::is_paused()
@@ -2212,8 +2231,8 @@ bool resolve_countries() const;
Sets or gets the flag that derermines if countries should be resolved for the peers of this
-torrent. It defaults to false. If it is set to true, the peer_info structure for the peers
-in this torrent will have their country member set. See peer_info for more information
+torrent. It defaults to false. If it is set to true, the peer_info structure for the peers
+in this torrent will have their country member set. See peer_info for more information
on how to interpret this field.
@@ -2235,7 +2254,7 @@ void auto_managed(bool m) const;
is_auto_managed() returns true if this torrent is currently auto managed.
auto_managed() changes whether the torrent is auto managed or not. For more info,
-see queuing.
has_metadata returns true if this torrent has metadata (either it was started from a
.torrent file or the metadata has been downloaded). The only scenario where this can return
false is when the torrent was started torrent-less (i.e. with just an info-hash and tracker
-ip). Note that if the torrent doesn't have metadata, the member get_torrent_info() will
+ip). Note that if the torrent doesn't have metadata, the member get_torrent_info() will
throw.
set_metadata expects the info section of metadata. i.e. The buffer passed in will be
hashed and verified against the info-hash. If it fails, a metadata_failed_alert will be
@@ -2283,7 +2302,7 @@ which this tracker is tried. If you want libtorrent to use another list of
trackers for this torrent, you can use replace_trackers() which takes
a list of the same form as the one returned from trackers() and will
replace it. If you want an immediate effect, you have to call
-force_reannounce().
add_tracker() will look if the specified tracker is already in the set.
If it is, it doesn't do anything. If it's not in the current set of trackers,
it will insert it in the tier specified in the announce_entry.
@@ -2304,7 +2323,7 @@ paused, queued, checking or seeding. url_seeds() return a set of the url seeds
currently in this torrent. Note that urls that fails may be removed
automatically from the list.
-
use_interface() sets the network interface this torrent will use when it opens outgoing
-connections. By default, it uses the same interface as the session uses to listen on. The
+connections. By default, it uses the same interface as the session uses to listen on. The
parameter must be a string containing an ip-address (either an IPv4 or IPv6 address). If
the string does not conform to this format and exception is thrown.
@@ -2387,10 +2406,10 @@ function, it means unlimited.
void save_resume_data() const;
-
save_resume_data() generates fast-resume data and returns it as an entry. This entry
-is suitable for being bencoded. For more information about how fast-resume works, see fast resume.
+
save_resume_data() generates fast-resume data and returns it as an entry. This entry
+is suitable for being bencoded. For more information about how fast-resume works, see fast resume.
This operation is asynchronous, save_resume_data will return immediately. The resume data
-is delivered when it's done through an save_resume_data_alert.
Note that by the time you receive the fast resume data, it may already be invalid if the torrent
is still downloading! The recommended practice is to first pause the session, then generate the
-fast resume data, and then close it down. Make sure to not remove_torrent() before you receive
-the save_resume_data_alert though. There's no need to pause when saving intermittent resume data.
+fast resume data, and then close it down. Make sure to not remove_torrent() before you receive
+the save_resume_data_alert though. There's no need to pause when saving intermittent resume data.
Warning
If you pause every torrent individually instead of pausing the session, every torrent
@@ -2420,7 +2439,7 @@ have their resume data saved when they complete and on exit, since their statist
In full allocation mode the reume data is never invalidated by subsequent
writes to the files, since pieces won't move around. This means that you don't need to
pause before writing resume data in full or sparse mode. If you don't, however, any data written to
-disk after you saved resume data and before the session closed is lost.
+disk after you saved resume data and before the session closed is lost.
It also means that if the resume data is out dated, libtorrent will not re-check the files, but assume
that it is fairly recent. The assumption is that it's better to loose a little bit than to re-check
@@ -2483,8 +2502,8 @@ torrent_status status() const;
status() will return a structure with information about the status of this
-torrent. If the torrent_handle is invalid, it will throw invalid_handle exception.
-See torrent_status.
get_peer_info() takes a reference to a vector that will be cleared and filled
with one entry for each peer connected to this torrent, given the handle is valid. If the
-torrent_handle is invalid, it will throw invalid_handle exception. Each entry in
-the vector contains information about that particular peer. See peer_info.
+torrent_handle is invalid, it will throw invalid_handle exception. Each entry in
+the vector contains information about that particular peer. See peer_info.
get_torrent_info()
@@ -2558,9 +2577,9 @@ the vector contains information about that particular peer. See torrent_info object associated with this torrent.
-This reference is valid as long as the torrent_handle is valid, no longer. If the
-torrent_handle is invalid or if it doesn't have any metadata, invalid_handle
+
Returns a const reference to the torrent_info object associated with this torrent.
+This reference is valid as long as the torrent_handle is valid, no longer. If the
+torrent_handle is invalid or if it doesn't have any metadata, invalid_handle
exception will be thrown. The torrent may be in a state without metadata only if
it was started without a .torrent file, i.e. by using the libtorrent extension of
just supplying a tracker and info-hash.
@@ -2576,7 +2595,7 @@ bool is_valid() const;
or if the torrent it refers to has been aborted. Note that a handle may become invalid after
it has been added to the session. Usually this is because the storage for the torrent is
somehow invalid or if the filenames are not allowed (and hence cannot be opened/created) on
-your filesystem. If such an error occurs, a file_error_alert is generated and all handles
+your filesystem. If such an error occurs, a file_error_alert is generated and all handles
that refers to that torrent will become invalid.
progress is a value in the range [0, 1], that represents the progress of the
@@ -2766,7 +2787,7 @@ be slightly smaller than the other rates, but if projected over a long time
num_peers is the number of peers this torrent currently is connected to.
Peer connections that are in the half-open state (is attempting to connect)
or are queued for later connection attempt do not count. Although they are
-visible in the peer list when you call get_peer_info().
num_complete and num_incomplete are set to -1 if the tracker did not
send any scrape data in its announce reply. This data is optional and may
not be available from all trackers. If these are not -1, they are the total
@@ -2804,7 +2825,7 @@ copies is set to -1.
block_size is the size of a block, in bytes. A block is a sub piece, it
is the number of bytes that each piece request asks for and the number of
bytes that each bit in the partial_piece_info's bitset represents
-(see get_download_queue()). This is typically 16 kB, but it may be
+(see get_download_queue()). This is typically 16 kB, but it may be
larger if the pieces are larger.
num_uploads is the number of unchoked peers in this torrent.
num_connections is the number of peer connections this torrent has, including
@@ -2814,7 +2835,7 @@ always <= num_peersconnections_limit is the set limit of number of connections for this torrent.
storage_mode is one of storage_mode_allocate, storage_mode_sparse or
storage_mode_compact. Identifies which storage mode this torrent is being saved
-with. See Storage allocation.
up_bandwidth_queue and down_bandwidth_queue are the number of peers in this
torrent that are waiting for more bandwidth quota from the torrent rate limiter.
This can determine if the rate you get from this torrent is bound by the torrents
@@ -2831,7 +2852,7 @@ seconds it has been active while being a seed.
seed_rank is a rank of how important it is to seed the torrent, it is used
to determine which torrents to seed and which to queue. It is based on the peer
-to seed ratio from the tracker scrape. For more information, see queuing.
+to seed ratio from the tracker scrape. For more information, see queuing.
last_scrape is the number of seconds since this torrent acquired scrape data.
If it has never done that, this value is -1.
has_incoming is true if there has ever been an incoming connection attempt
@@ -2839,6 +2860,9 @@ to this torrent.'
sparse_regions the number of regions of non-downloaded pieces in the
torrent. This is an interesting metric on windows vista, since there is
a limit on the number of sparse regions in a single file there.
+
seed_mode is true if the torrent is in seed_mode. If the torrent was
+started in seed mode, it will leave seed mode once all pieces have been
+checked or as soon as one piece fails the hash check.
peer_info
@@ -2973,7 +2997,7 @@ any combination of the enums above. The following table describes each flag:
up_speed and down_speed contains the current upload and download speed
we have to and from this peer (including any protocol messages). The transfer rates
of payload data only are found in payload_up_speed and payload_down_speed.
@@ -3116,12 +3140,12 @@ and used for the peer's send buffer, respectively.
allocated and used as receive buffer, respectively.
num_hashfails is the number of pieces this peer has participated in
sending us that turned out to fail the hash check.
country is the two letter ISO 3166 country code for the country the peer
is connected from. If the country hasn't been resolved yet, both chars are set
to 0. If the resolution failed for some reason, the field is set to "--". If the
resolution service returns an invalid country code, it is set to "!!".
The countries.nerd.dk service is used to look up countries. This field will
-remain set to 0 unless the torrent is set to resolve countries, see resolve_countries().
+remain set to 0 unless the torrent is set to resolve countries, see resolve_countries().
inet_as_name is the name of the AS this peer is located in. This might be
an empty string if there is no name in the geo ip database.
inet_as is the AS number the peer is located in.
@@ -3254,6 +3278,8 @@ struct session_settings
int seeding_piece_quota;
int max_sparse_regions;
+
+ bool lock_disk_cache;
};
user_agent this is the client identification to the tracker.
@@ -3383,9 +3409,9 @@ message or a time out.
are kept in memory after the torrent becomes a seed or not. If it is set to
true the hashes are freed once the torrent is a seed (they're not
needed anymore since the torrent won't download anything more). If it's set
-to false they are not freed. If they are freed, the torrent_info returned
+to false they are not freed. If they are freed, the torrent_info returned
by get_torrent_info() will return an object that may be incomplete, that
-cannot be passed back to add_torrent() for instance.
+cannot be passed back to add_torrent() for instance.
upnp_ignore_nonrouters indicates whether or not the UPnP implementation
should ignore any broadcast response from a device whose address is not the
configured router for this machine. i.e. it's a way to not talk to other
@@ -3428,7 +3454,7 @@ to peers if a previous socket to that peer and port is in peer_tos determines the TOS byte set in the IP header of every packet
sent to peers (including web seeds). The default value for this is 0x0
(no marking). One potentially useful TOS mark is 0x20, this represents
-the QBone scavenger service. For more details, see QBSS.
+the QBone scavenger service. For more details, see QBSS.
active_downloads and active_seeds controls how many active seeding and
downloading torrents the queuing mechanism allows. The target number of active
torrents is min(active_downloads+active_seeds,active_limit).
@@ -3451,12 +3477,12 @@ slow torrents.
auto_manage_interval is the number of seconds between the torrent queue
is updated, and rotated.
share_ratio_limit is the upload / download ratio limit for considering a
-seeding torrent have met the seed limit criteria. See queuing.
+seeding torrent have met the seed limit criteria. See queuing.
seed_time_ratio_limit is the seeding time / downloading time ratio limit
-for considering a seeding torrent to have met the seed limit criteria. See queuing.
+for considering a seeding torrent to have met the seed limit criteria. See queuing.
seed_time_limit is the limit on the time a torrent has been an active seed
(specified in seconds) before it is considered having met the seed limit criteria.
-See queuing.
close_redundant_connections specifies whether libtorrent should close
connections where both ends have no utility in keeping the connection open.
For instance if both ends have completed their downloads, there's no point
@@ -3519,6 +3545,9 @@ limit is not hard, it will be exceeded. Once it's exceeded, pieces
that will maintain or decrease the number of sparse regions are
prioritized. To disable this functionality, set this to 0. It defaults
to 0 on all platforms except windows.
+
lock_disk_cache if lock disk cache is set to true the disk cache
+that's in use, will be locked in physical memory, preventing it from
+being swapped out.
pe_settings
@@ -3616,16 +3645,16 @@ options are available:
none - This is the default, no proxy server is used, all other fields
are ignored.
-
socks4 - The server is assumed to be a SOCKS4 server that
+
socks4 - The server is assumed to be a SOCKS4 server that
requires a username.
-
socks5 - The server is assumed to be a SOCKS5 server (RFC 1928) that
+
socks5 - The server is assumed to be a SOCKS5 server (RFC 1928) that
does not require any authentication. The username and password are ignored.
socks5_pw - The server is assumed to be a SOCKS5 server that supports
-plain text username and password authentication (RFC 1929). The username
+plain text username and password authentication (RFC 1929). The username
and password specified may be sent to the proxy if it requires.
http - The server is assumed to be an HTTP proxy. If the transport used
for the connection is non-HTTP, the server is assumed to support the
-CONNECT method. i.e. for web seeds and HTTP trackers, a plain proxy will
+CONNECT method. i.e. for web seeds and HTTP trackers, a plain proxy will
suffice. The proxy is assumed to not require authorization. The username
and password will not be used.
http_pw - The server is assumed to be an HTTP proxy that requires
@@ -3873,7 +3902,7 @@ sure not to clash with anybody else. Here are some taken id's:
-
There's currently an informal directory of client id's here.
+
There's currently an informal directory of client id's here.
The major, minor, revision and tag parameters are used to identify the
version of your client. All these numbers must be within the range [0, 9].
to_string() will generate the actual string put in the peer-id, and return it.
@@ -3924,13 +3953,13 @@ int add_mapping(protocol_type p, int external_port, int local_port);
natpmp::udp for the NAT-PMP class.
external_port is the port on the external address that will be mapped. This
is a hint, you are not guaranteed that this port will be available, and it may
-end up being something else. In the portmap_alert notification, the actual
+end up being something else. In the portmap_alert notification, the actual
external port is reported.
local_port is the port in the local machine that the mapping should forward
to.
The return value is an index that identifies this port mapping. This is used
-to refer to mappings that fails or succeeds in the portmap_error_alert and
-portmap_alert respectively. If The mapping fails immediately, the return value
+to refer to mappings that fails or succeeds in the portmap_error_alert and
+portmap_alert respectively. If The mapping fails immediately, the return value
is -1, which means failure. There will not be any error alert notification for
mappings that fail with a -1 return value.
These functions will encode data to bencoded or decode bencoded data.
-
The entry class is the internal representation of the bencoded data
-and it can be used to retrieve information, an entry can also be build by
+
These functions will encode data to bencoded or decode bencoded data.
+
The entry class is the internal representation of the bencoded data
+and it can be used to retrieve information, an entry can also be build by
the program and given to bencode() to encode it into the OutIt
iterator.
@@ -4032,8 +4061,8 @@ torrent_handle add_magnet_uri(session& ses, std::string const& uri
and adds the torrent to the specified session (ses). It returns the
handle to the newly added torrent, or an invalid handle in case parsing
failed. To control some initial settings of the torrent, sepcify those in
-the add_torrent_params, p. See add_torrent().
-
For more information about magnet links, see magnet links.
Generates a magnet URI from the specified torrent. If the torrent
handle is invalid, an empty string is returned.
-
For more information about magnet links, see magnet links.
+
For more information about magnet links, see magnet links.
@@ -4055,7 +4084,7 @@ been posted by libtorrent pop_ale
auto_ptr object. If there is an alert in libtorrent's queue, the alert
from the front of the queue is popped and returned.
You can then use the alert object and query
-
By default, only errors are reported. set_alert_mask() can be
used to specify which kinds of events should be reported. The alert mask
is a bitmask with the following bits:
@@ -4120,7 +4149,7 @@ alerts that belong to an enabled category are posted. Setting the alert bitmask
all alerts
When you get an alert, you can use typeid() or dynamic_cast<> to get more detailed
information on exactly which type it is. i.e. what kind of error it is. You can also use a
-dispatcher mechanism that's available in libtorrent.
+dispatcher mechanism that's available in libtorrent.
All alert types are defined in the <libtorrent/alert_types.hpp> header file.
The alert class is the base class that specific messages are derived from. This
is its synopsis:
This alert is posted when the asynchronous read operation initiated by
-a call to read_piece() is completed. If the read failed, the torrent
+a call to read_piece() is completed. If the read failed, the torrent
is paused and an error state is set and the buffer member of the alert
is 0. If successful, buffer points to a buffer containing all the data
of the piece. piece is the piece index that was read. size is the
@@ -4218,7 +4247,7 @@ struct external_ip_alert: alert
listen_failed_alert
This alert is generated when none of the ports, given in the port range, to
-session can be opened for listening. This alert doesn't have any extra
+session can be opened for listening. This alert doesn't have any extra
data members.
@@ -4230,7 +4259,7 @@ case it appears the client is not running on a NAT:ed network or if it
appears there is no NAT router that can be remote controlled to add port
mappings.
mapping refers to the mapping index of the port map that failed, i.e.
-the index returned from add_mapping.
struct portmap_error_alert: alert
@@ -4248,7 +4277,7 @@ a port was successfully mapped on it. On a NAT:ed network with a NAT-PMP
capable router, this is typically generated once when mapping the TCP
port and, if DHT is enabled, when the UDP port is mapped.
mapping refers to the mapping index of the port map that failed, i.e.
-the index returned from add_mapping.
This is a debug alert that is generated by an incoming invalid piece request.
-Ïp is the address of the peer and the request is the actual incoming
+ìp is the address of the peer and the request is the actual incoming
request from the peer.
struct invalid_request_alert: torrent_alert
@@ -4695,7 +4724,7 @@ including <libtorrent/alert.hp
here's a complete list with description.
invalid_handle
-
This exception is thrown when querying information from a torrent_handle that hasn't
+
This exception is thrown when querying information from a torrent_handle that hasn't
been initialized or that has become invalid.
This is thrown by add_torrent() if the torrent already has been added to
-the session. Since remove_torrent() is asynchronous, this exception may
+
This is thrown by add_torrent() if the torrent already has been added to
+the session. Since remove_torrent() is asynchronous, this exception may
be thrown if the torrent is removed and then immediately added again.
@@ -4785,38 +4822,17 @@ will create directories and empty files at this point. If ftruncate all files to their target size.
Returning true indicates an error occurred.
-
-
readv()
+
+
readv() writev()
int readv(file::iovec_t const* buf, int slot, int offset, int num_bufs) = 0;
-
-
-
This function should read the data in the given slot and at the given offset.
-It should read num_bufs buffers, where the size of each buffer is specified in the
-buffer array bufs. The file::iovec_t type has the following members:
The return value is the number of bytes actually read.
-
Every buffer in bufs can be assumed to be page aligned and be of a page aligned size,
-except for the last buffer of the torrent. The buffer can be assumed to fit a fully page
-aligned number of bytes though.
-
-
-
writev()
-
-
int write(const char* buf, int slot, int offset, int size) = 0;
-
This function should write the data to the given slot and at the given offset.
-It should write num_bufs buffers, where the size of each buffer is specified in the
-buffer array bufs. The file::iovec_t type has the following members:
+
These functions should read or write the data in or to the given slot at the given offset.
+It should read or write num_bufs buffers sequentially, where the size of each buffer
+is specified in the buffer array bufs. The file::iovec_t type has the following members:
The return value is the number of bytes actually written.
+
The return value is the number of bytes actually read or written, or -1 on failure. If
+it returns -1, the error code is expected to be set to
Every buffer in bufs can be assumed to be page aligned and be of a page aligned size,
-except for the last buffer of the torrent. The buffer can be assumed to fit a fully page
-aligned number of bytes though.
-This function should write the data in buf to the given slot (slot) at offset
-offset in that slot. The buffer size is size.
+except for the last buffer of the torrent. The allocated buffer can be assumed to fit a
+fully page aligned number of bytes though. This is useful when reading and writing the
+last piece of a file in unbuffered mode.
+
The offset is aligned to 16 kiB boundries most of the time, but there are rare
+exceptions when it's not. Specifically if the read cache is disabled/or full and a
+client requests unaligned data, or the file itself is not aligned in the torrent.
+Most clients request aligned data.
move_storage()
@@ -4961,6 +4981,22 @@ bool delete_files() = 0;
This function should delete all files and directories belonging to this storage.
Returning true indicates an error occurred.
+
The disk_buffer_pool is used to allocate and free disk buffers. It has the
+following members:
@@ -4979,9 +5015,9 @@ torrents are being downloaded at any given time, and once a torrent is completel
downloaded, the next in line is started.
Torrents that are auto managed are subject to the queuing and the active torrents
limits. To make a torrent auto managed, set auto_managed to true when adding the
-torrent (see add_torrent()).
The limits of the number of downloading and seeding torrents are controlled via
-active_downloads, active_seeds and active_limit in session_settings.
+active_downloads, active_seeds and active_limit in session_settings.
These limits takes non auto managed torrents into account as well. If there are
more non-auto managed torrents being downloaded than the active_downloads
setting, any auto managed torrents will be queued until torrents are removed so
@@ -4989,9 +5025,9 @@ that the number drops below the limit.
The default values are 8 active downloads and 5 active seeds.
At a regular interval, torrents are checked if there needs to be any re-ordering of
which torrents are active and which are queued. This interval can be controlled via
-auto_manage_interval in session_settings. It defaults to every 30 seconds.
+auto_manage_interval in session_settings. It defaults to every 30 seconds.
For queuing to work, resume data needs to be saved and restored for all torrents.
-See save_resume_data().
@@ -5014,20 +5050,20 @@ seeding. A seed cycle is completed when a torrent meets either the share ratio l
(uploaded bytes / downloaded bytes), the share time ratio (time seeding / time
downloaing) or seed time limit (time seeded).
The relevant settings to control these limits are share_ratio_limit,
-seed_time_ratio_limit and seed_time_limit in session_settings.
The fast resume mechanism is a way to remember which pieces are downloaded
and where they are put between sessions. You can generate fast resume data by
-calling save_resume_data() on torrent_handle. You can
+calling save_resume_data() on torrent_handle. You can
then save this data to disk and use it when resuming the torrent. libtorrent
will not check the piece hashes then, and rely on the information given in the
fast-resume data. The fast-resume data also contains information about which
blocks, in the unfinished pieces, were downloaded, so it will not have to
start from scratch on the partially downloaded pieces.
-
To use the fast-resume data you simply give it to add_torrent(), and it
+
To use the fast-resume data you simply give it to add_torrent(), and it
will skip the time consuming checks. It may have to do the checking anyway, if
the fast-resume data is corrupt or doesn't fit the storage for that torrent,
then it will not trust the fast-resume data and just do the checking.
@@ -5172,7 +5208,7 @@ pieces that have been downloaded.
to where they belong. This is the recommended (and default) mode.
The allocation mode is selected when a torrent is started. It is passed as an
-argument to session::add_torrent() (see add_torrent()).
+argument to session::add_torrent() (see add_torrent()).
The decision to use full allocation or compact allocation typically depends on whether
any files are filtered and if the filesystem supports sparse files.
@@ -5189,7 +5225,7 @@ as much space as has been downloaded.
full allocation
-
When a torrent is started in full allocation mode, the disk-io thread (see threads)
+
When a torrent is started in full allocation mode, the disk-io thread (see threads)
will make sure that the entire storage is allocated, and fill any gaps with zeros.
This will be skipped if the filesystem supports sparse files or automatic zero filling.
It will of course still check for existing pieces and fast resume data. The main
@@ -5270,7 +5306,7 @@ contain any piece), return that slot index.
These extensions all operates within the extension protocol. The
name of the extension is the name used in the extension-list packets,
and the payload is the data in the extended message (not counting the
length-prefix, message-id nor extension-id).
@@ -5401,11 +5437,11 @@ doesn't have any metadata.
HTTP seeding
There are two kinds of HTTP seeding. One with that assumes a smart
(and polite) client and one that assumes a smart server. These
-are specified in BEP 19 and BEP 17 respectively.
libtorrent supports both. In the libtorrent source code and API,
BEP 19 urls are typically referred to as url seeds and BEP 17
urls are typically referred to as HTTP seeds.
-
The libtorrent implementation of BEP 19 assumes that, if the URL ends with a slash
+
The libtorrent implementation of BEP 19 assumes that, if the URL ends with a slash
('/'), the filename should be appended to it in order to request pieces from
that file. The way this works is that if the torrent is a single-file torrent,
only that filename is appended. If the torrent is a multi-file torrent, the
@@ -5422,21 +5458,7 @@ altogether. You can use:
+
+++