half-started torrents

In addition to the downloading and seeding limits, there are limits on actions torrents perform. The downloading and seeding limits control whether peers are allowed at all, and if peers are not allowed, torrents are stopped and don't do anything. If peers are allowed, torrents may:

1. announce to trackers
2. announce to the DHT
3. announce to local peer discovery (local service discovery)

Each of those actions are associated with a cost and hence may need a separate limit. These limits are controlled by settings_pack::active_tracker_limit, settings_pack::active_dht_limit and settings_pack::active_lsd_limit respectively.

Specifically, announcing to a tracker is typically cheaper than announcing to the DHT. active_dht_limit will limit the number of torrents that are allowed to announce to the DHT. The highest priority ones will, and the lower priority ones won't. The will still be considered started though, and any incoming peers will still be accepted.

If you do not wish to impose such limits (basically, if you do not wish to have half-started torrents) make sure to set these limits to -1 (infinite).

prefer seeds

In the case where active_downloads + active_seeds > active_limit, there's an ambiguity whether the downloads should be satisfied first or the seeds. To disambiguate this case, the settings_pack::auto_manage_prefer_seeds determines whether seeds are preferred or not.

inactive torrents

Torrents that are not transferring any bytes (downloading or uploading) have a relatively low cost to be started. It's possible to exempt such torrents from the download and seed queues by setting settings_pack::dont_count_slow_torrents to true.

Since it sometimes may take a few minutes for a newly started torrent to find peers and be unchoked, or find peers that are interested in requesting data, torrents are not considered inactive immadiately. There must be an extended period of no transfers before it is considered inactive and exempt from the queuing limits.

operator==()

bool operator== (web_seed_entry const& e) const;

URL and type comparison

operator<()

bool operator< (web_seed_entry const& e) const;

URL and type less-than comparison

enum type_t

Declared in "libtorrent/torrent_info.hpp"

url

The URL of the web seed

auth

Optional authentication. If this is set, it's passed in as HTTP basic auth to the web seed. The format is: username:password.

extra_headers

Any extra HTTP headers that need to be passed to the web seed

type

The type of web seed (see type_t)

torrent_info()

explicit torrent_info (bdecode_node const& torrent_file);
explicit torrent_info (span<char const> buffer, from_span_t);
torrent_info (char const* buffer, int size, error_code& ec);
torrent_info (span<char const> buffer, error_code& ec, from_span_t);
torrent_info (std::string const& filename, error_code& ec);
torrent_info (bdecode_node const& torrent_file, error_code& ec);
torrent_info (char const* buffer, int size);
explicit torrent_info (sha1_hash const& info_hash);
explicit torrent_info (std::string const& filename);
torrent_info (torrent_info const& t);

The constructor that takes an info-hash will initialize the info-hash to the given value, but leave all other fields empty. This is used internally when downloading torrents without the metadata. The metadata will be created by libtorrent as soon as it has been downloaded from the swarm.

The constructor that takes a bdecode_node will create a torrent_info object from the information found in the given torrent_file. The bdecode_node represents a tree node in an bencoded file. To load an ordinary .torrent file into a bdecode_node, use bdecode().

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 the constructor, for convenience. This might not be the most suitable for applications that want to be able to report detailed errors on what might go wrong.

There is an upper limit on the size of the torrent file that will be loaded by the overload taking a filename. If it's important that even very large torrent files are loaded, use one of the other overloads.

The overloads that takes an error_code const& never throws if an error occur, they will simply set the error code to describe what went wrong and not fully initialize the torrent_info object. The overloads that do not take the extra error_code parameter will always throw if an error occurs. These overloads are not available when building without exception support.

The overload that takes a span also needs an extra parameter of type from_span_t to disambiguate the std::string overload for string literals. There is an object in the libtorrent namespace of this type called from_span.

~torrent_info()

~torrent_info ();

frees all storage associated with this torrent_info object

orig_files() files()

file_storage const& files () const;
file_storage const& orig_files () const;

The file_storage object contains the information on how to map the pieces to files. It is separated from the torrent_info object because when creating torrents a storage object needs to be created without having a torrent file. When renaming files in a storage, the storage needs to make its own copy of the file_storage in order to make its mapping differ from the one in the torrent file.

orig_files() returns the original (unmodified) file storage for this torrent. This is used by the web server connection, which needs to request files with the original names. Filename may be changed using torrent_info::rename_file().

For more information on the file_storage object, see the separate document on how to create torrents.

rename_file()

void rename_file (file_index_t index, std::string const& new_filename);

Renames a the file with the specified index to the new name. The new filename is reflected by the file_storage returned by files() but not by the one returned by orig_files().

If you want to rename the base name of the torrent (for a multi file torrent), you can copy the file_storage (see files() and orig_files() ), change the name, and then use remap_files().

The new_filename can both be a relative path, in which case the file name is relative to the save_path of the torrent. If the new_filename is an absolute path (i.e. is_complete(new_filename) == true), then the file is detached from the save_path of the torrent. In this case the file is not moved when move_storage() is invoked.

remap_files()

void remap_files (file_storage const& f);

Remaps the file storage to a new file layout. This can be used to, for instance, download all data in a torrent to a single file, or to a number of fixed size sector aligned files, regardless of the number and sizes of the files in the torrent.

The new specified file_storage must have the exact same size as the current one.

trackers() add_tracker()

std::vector<announce_entry> const& trackers () const;
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. The trackers() function will return a sorted vector of announce_entry. Each announce entry contains a string, which is the tracker url, and a tier index. The tier index is the high-level priority. No matter which trackers that works or not, the ones with lower tier will always be tried before the one with higher tier number. For more information, see announce_entry.

collections() similar_torrents()

std::vector<sha1_hash> similar_torrents () const;
std::vector<std::string> collections () const;

These two functions are related to BEP 38 (mutable torrents). The vectors returned from these correspond to the "similar" and "collections" keys in the .torrent file. Both info-hashes and collections from within the info-dict and from outside of it are included.

add_url_seed() set_web_seeds() add_http_seed() web_seeds()

void add_url_seed (std::string const& url
      , std::string const& extern_auth = std::string()
      , web_seed_entry::headers_t const& extra_headers = web_seed_entry::headers_t());
std::vector<web_seed_entry> const& web_seeds () const;
void set_web_seeds (std::vector<web_seed_entry> seeds);
void add_http_seed (std::string const& url
      , std::string const& extern_auth = std::string()
      , web_seed_entry::headers_t const& extra_headers = web_seed_entry::headers_t());

web_seeds() returns all url seeds and http seeds in the torrent. Each entry is a web_seed_entry and may refer to either a url seed or http seed.

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.

set_web_seeds() replaces all web seeds with the ones specified in the seeds vector.

The extern_auth argument can be used for other authorization schemes than basic HTTP authorization. If set, it will override any username and password found in the URL itself. The string will be sent as the HTTP authorization header's value (without specifying "Basic").

The extra_headers argument defaults to an empty list, but can be used to insert custom HTTP headers in the requests to a specific web seed.

See http seeding for more information.

piece_length() num_pieces() total_size()

std::int64_t total_size () const;
int num_pieces () const;
int piece_length () const;

total_size(), piece_length() and num_pieces() returns the total number of bytes the torrent-file represents (all the files in it), the number of byte for each piece and the total number of pieces, respectively. The difference between piece_size() and piece_length() is that piece_size() takes the piece index as argument and gives you the exact size of that piece. It will always be the same as piece_length() except in the case of the last piece, which may be smaller.

piece_range() last_piece() end_piece()

piece_index_t last_piece () const;
index_range<piece_index_t> piece_range () const;
piece_index_t end_piece () const;

last_piece() returns the index to the last piece in the torrent and end_piece() returns the index to the one-past-end piece in the torrent piece_range() returns an implementation-defined type that can be used as the container in a range-for loop. Where the values are the indices of all pieces in the file_storage.

info_hash()

const sha1_hash& info_hash () const;

returns the info-hash of the torrent

num_files()

int num_files () const;

If you need index-access to files you can use the num_files() along with the file_path(), file_size()-family of functions to access files using indices.

map_block()

std::vector<file_slice> map_block (piece_index_t const piece
      , std::int64_t offset, int size) const;

This function will map a piece index, a byte offset within that piece and a size (in bytes) into the corresponding files with offsets where that data for that piece is supposed to be stored. See file_slice.

map_file()

peer_request map_file (file_index_t const file, std::int64_t offset, int size) const;

This function will map a range in a specific file into a range in the torrent. The file_offset parameter is the offset in the file, given in bytes, where 0 is the start of the file. See peer_request.

The input range is assumed to be valid within the torrent. file_offset + size is not allowed to be greater than the file size. file_index must refer to a valid file, i.e. it cannot be >= num_files().

ssl_cert()

string_view ssl_cert () const;

Returns the SSL root certificate for the torrent, if it is an SSL torrent. Otherwise returns an empty string. The certificate is the the public certificate in x509 format.

is_valid()

bool is_valid () const;

returns true if this torrent_info object has a torrent loaded. This is primarily used to determine if a magnet link has had its metadata resolved yet or not.

priv()

bool priv () const;

returns true if this torrent is private. i.e., the client should not advertise itself on the trackerless network (the Kademlia DHT) for this torrent.

is_i2p()

bool is_i2p () const;

returns true if this is an i2p torrent. This is determined by whether or not it has a tracker whose URL domain name ends with ".i2p". i2p torrents disable the DHT and local peer discovery as well as talking to peers over anything other than the i2p network.

piece_size()

int piece_size (piece_index_t index) const;

returns the piece size of file with index. This will be the same as piece_length(), except for the last piece, which may be shorter.

hash_for_piece_ptr() hash_for_piece()

char const* hash_for_piece_ptr (piece_index_t const index) const;
sha1_hash hash_for_piece (piece_index_t 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. hash_for_piece_ptr() returns a pointer to the 20 byte sha1 digest for the piece. Note that the string is not 0-terminated.

set_merkle_tree() merkle_tree()

std::vector<sha1_hash> const& merkle_tree () const;
void set_merkle_tree (std::vector<sha1_hash>& h);

merkle_tree() returns a reference to the merkle tree for this torrent, if any. set_merkle_tree() moves the passed in merkle tree into the torrent_info object. i.e. h will not be identical after the call. You need to set the merkle tree for a torrent that you've just created (as a merkle torrent). The merkle tree is retrieved from the create_torrent::merkle_tree() function, and need to be saved separately from the torrent file itself. Once it's added to libtorrent, the merkle tree will be persisted in the resume data.

name()

const std::string& name () const;

name() returns the name of the torrent. name contains UTF-8 encoded string.

creation_date()

std::time_t creation_date () const;

creation_date() returns the creation date of the torrent as time_t (posix time). If there's no time stamp in the torrent file, the optional object will be uninitialized. .. posix time: http://www.opengroup.org/onlinepubs/009695399/functions/time.html

creator()

const std::string& creator () const;

creator() returns the creator string in the torrent. If there is no creator string it will return an empty string.

comment()

const std::string& comment () const;

comment() returns the comment associated with the torrent. If there's no comment, it will return an empty string. comment contains UTF-8 encoded string.

nodes()

std::vector<std::pair<std::string, int>> const& nodes () const;

If this torrent contains any DHT nodes, they are put in this vector in their original form (host name and port number).

add_node()

void add_node (std::pair<std::string, int> const& node);

This is used when creating torrent. Use this to add a known DHT node. It may be used, by the client, to bootstrap into the DHT network.

parse_info_section()

bool parse_info_section (bdecode_node const& e, error_code& ec);

populates the torrent_info by providing just the info-dict buffer. This is used when loading a torrent from a magnet link for instance, where we only have the info-dict. The bdecode_node e points to a parsed info-dictionary. ec returns an error code if something fails (typically if the info dictionary is malformed).

info()

bdecode_node info (char const* key) const;

This function looks up keys from the info-dictionary of the loaded torrent file. It can be used to access extension values put in the .torrent file. If the specified key cannot be found, it returns nullptr.

swap()

void swap (torrent_info& ti);

swap the content of this and ti.

metadata_size() metadata()

int metadata_size () const;
boost::shared_array<char> metadata () const;

metadata() returns a the raw info section of the torrent file. The size of the metadata is returned by metadata_size().

is_merkle_torrent()

bool is_merkle_torrent () const;

returns whether or not this is a merkle torrent. see BEP 30.

session_proxy() ~session_proxy() operator=()

session_proxy (session_proxy&&) noexcept;
session_proxy& operator= (session_proxy const&);
~session_proxy ();
session_proxy& operator= (session_proxy&&) noexcept;
session_proxy ();
session_proxy (session_proxy const&);

default constructor, does not refer to any session implementation object.

session_params()

explicit session_params (settings_pack&& sp);
explicit session_params (settings_pack const& sp);
session_params ();

This constructor can be used to start with the default plugins (ut_metadata, ut_pex and smart_ban). The default values in the settings is to start the default features like upnp, NAT-PMP, and dht for example.

session_params()

session_params (settings_pack&& sp
      , std::vector<std::shared_ptr<plugin>> exts);
session_params (settings_pack const& sp
      , std::vector<std::shared_ptr<plugin>> exts);

This constructor helps to configure the set of initial plugins to be added to the session before it's started.

session()

explicit session (session_params&& params);
session ();
explicit session (session_params const& params);

Constructs the session objects which acts as the container of torrents. In order to avoid a race condition between starting the session and configuring it, you can pass in a session_params object. Its settings will take effect before the session starts up.

session()

session (session_params&& params, io_service& ios);
session (session_params const& params, io_service& ios);

Overload of the constructor that takes an external io_service to run the session object on. This is primarily useful for tests that may want to run multiple sessions on a single io_service, or low resource systems where additional threads are expensive and sharing an io_service with other events is fine.

session()

session (settings_pack const& pack
      , session_flags_t const flags = add_default_plugins);
session (settings_pack&& pack
      , session_flags_t const flags = add_default_plugins);

Constructs the session objects which acts as the container of torrents. It provides configuration options across torrents (such as rate limits, disk cache, ip filter etc.). In order to avoid a race condition between starting the session and configuring it, you can pass in a settings_pack object. Its settings will take effect before the session starts up.

The flags parameter 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 features. If you do not want them to start, pass 0 as the flags parameter.

session() operator=()

session (session&&) = default;
session& operator= (session&&) = default;

movable

session() operator=()

session& operator= (session const&) = delete;
session (session const&) = delete;

non-copyable

session()

session (settings_pack&& pack
      , io_service& ios
      , session_flags_t const flags = add_default_plugins);
session (settings_pack const& pack
      , io_service& ios
      , session_flags_t const flags = add_default_plugins);

overload of the constructor that takes an external io_service to run the session object on. This is primarily useful for tests that may want to run multiple sessions on a single io_service, or low resource systems where additional threads are expensive and sharing an io_service with other events is fine.

~session()

~session ();

The destructor of session will notify all trackers that our torrents have been shut down. If some trackers are down, they will time out. All this before the destructor of session returns. So, it's advised that any kind of interface (such as windows) are closed before destructing the session object. Because it can take a few second for it to finish. The timeout can be set with apply_settings().

abort()

session_proxy abort ();

In case you want to destruct the session asynchronously, you can request a session destruction proxy. If you don't do this, the destructor of the session object will block while the trackers are contacted. If you keep one session_proxy to the session when destructing it, the destructor will not block, but start to close down the session, the destructor of the proxy will then synchronize the threads. So, the destruction of the session is performed from the session destructor call until the session_proxy destructor call. The session_proxy does not have any operations on it (since the session is being closed down, no operations are allowed on it). The only valid operation is calling the destructor:

class session_proxy
{
public:
        session_proxy();
        ~session_proxy()
};

reset()

void reset ();

reset announce counters and clears the started sent flag. The announce_endpoint will look like we've never talked to the tracker.

failed()

void failed (int backoff_ratio, seconds32 retry_interval = seconds32(0));

updates the failure counter and time-outs for re-trying. This is called when the tracker announce fails.

can_announce()

bool can_announce (time_point now, bool is_seed, std::uint8_t fail_limit) const;

returns true if we can announce to this tracker now. The current time is passed in as now. The is_seed argument is necessary because once we become a seed, we need to announce right away, even if the re-announce timer hasn't expired yet.

is_working()

bool is_working () const;

returns true if the last time we tried to announce to this tracker succeeded, or if we haven't tried yet.

message

if this tracker has returned an error or warning message that message is stored here

last_error

if this tracker failed the last time it was contacted this error code specifies what error occurred

local_endpoint

the local endpoint of the listen interface associated with this endpoint

scrape_incomplete scrape_complete

if this tracker has returned scrape data, these fields are filled in with valid numbers. Otherwise they are set to -1. the number of current downloaders

fails

the number of times in a row we have failed to announce to this tracker.

updating

true while we're waiting for a response from the tracker.

start_sent

set to true when we get a valid response from an announce with event=started. If it is set, we won't send start in the subsequent announces.

complete_sent

set to true when we send a event=completed.

announce_entry() ~announce_entry() operator=()

announce_entry ();
announce_entry (announce_entry const&);
~announce_entry ();
announce_entry& operator= (announce_entry const&);
explicit announce_entry (string_view u);

constructs a tracker announce entry with u as the URL.

reset()

void reset ();

reset announce counters and clears the started sent flag. The announce_entry will look like we've never talked to the tracker.

trim()

void trim ();

trims whitespace characters from the beginning of the URL.

enum tracker_source

Declared in "libtorrent/announce_entry.hpp"

url

tracker URL as it appeared in the torrent file

trackerid

the current &trackerid= argument passed to the tracker. this is optional and is normally empty (in which case no trackerid is sent).

tier

the tier this tracker belongs to

fail_limit

the max number of failures to announce to this tracker in a row, before this tracker is not used anymore. 0 means unlimited

source

a bitmask specifying which sources we got this tracker from.

verified

set to true the first time we receive a valid response from this tracker.

operator==()

bool operator== (peer_request const& r) const;

returns true if the right hand side peer_request refers to the same range as this does.

piece

the index of the piece in which the range starts.

start

the offset within that piece where the range starts.

length

the size of the range, in bytes.

set_peer() peer()

void set_peer (tcp::endpoint const& ep);
tcp::endpoint peer () const;

The peer is the ip address of the peer this block was downloaded from.

enum block_state_t

Declared in "libtorrent/torrent_handle.hpp"

bytes_progress

the number of bytes that have been received for this block

block_size

the total number of bytes in this block.

state

the state this block is in (see block_state_t)

num_peers

the number of peers that is currently requesting this block. Typically this is 0 or 1, but at the end of the torrent blocks may be requested by more peers in parallel to speed things up.

torrent_handle()

torrent_handle () noexcept = default;

constructs a torrent handle that does not refer to a torrent. i.e. is_valid() will return false.

add_piece()

void add_piece (piece_index_t piece, char const* data, add_piece_flags_t flags = {}) const;

This function will write data to the storage as piece piece, as if it had been downloaded from a peer. data is expected to point to a buffer of as many bytes as the size of the specified piece. The data in the buffer is copied and passed on to the disk IO thread to be written at a later point.

By default, data that's already been downloaded is not overwritten by this buffer. If you trust this data to be correct (and pass the piece hash check) you may pass the overwrite_existing flag. This will instruct libtorrent to overwrite any data that may already have been downloaded with this data.

Since the data is written asynchronously, you may know that is passed or failed the hash check by waiting for piece_finished_alert or hash_failed_alert.

read_piece()

void read_piece (piece_index_t piece) const;

This function starts an asynchronous read operation of the specified piece from 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. Since this alert is a response to an explicit call, it will always be posted, regardless of the 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.

have_piece()

bool have_piece (piece_index_t piece) const;

Returns true if this piece has been completely downloaded, and false otherwise.

get_peer_info()

void get_peer_info (std::vector<peer_info>& v) const;

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 system_error exception. Each entry in the vector contains information about that particular peer. See peer_info.

status()

torrent_status status (status_flags_t flags = status_flags_t::all()) const;

status() will return a structure with information about the status of this torrent. If the torrent_handle is invalid, it will throw system_error exception. See torrent_status. The flags argument filters what information is returned in the torrent_status. Some information in there is relatively expensive to calculate, and if you're not interested in it (and see performance issues), you can filter them out.

By default everything is included. The flags you can use to decide what to include are defined in the status_flags_t enum.

get_download_queue()

void get_download_queue (std::vector<partial_piece_info>& queue) const;

get_download_queue() takes a non-const reference to a vector which it will fill with information about pieces that are partially downloaded or not downloaded at all but partially requested. See partial_piece_info for the fields in the returned vector.

clear_piece_deadlines() reset_piece_deadline() set_piece_deadline()

void clear_piece_deadlines () const;
void reset_piece_deadline (piece_index_t index) const;
void set_piece_deadline (piece_index_t index, int deadline, deadline_flags_t flags = {}) const;

This function sets or resets the deadline associated with a specific piece index (index). libtorrent will attempt to download this entire piece before the deadline expires. This is not necessarily possible, but pieces with a more recent deadline will always be prioritized over pieces with a deadline further ahead in time. The deadline (and flags) of a piece can be changed by calling this function again.

If the piece is already downloaded when this call is made, nothing happens, unless the alert_when_available flag is set, in which case it will have the same effect as calling read_piece() for index.

deadline is the number of milliseconds until this piece should be completed.

reset_piece_deadline removes the deadline from the piece. If it hasn't already been downloaded, it will no longer be considered a priority.

clear_piece_deadlines() removes deadlines on all pieces in the torrent. As if reset_piece_deadline() was called on all pieces.

file_progress()

void file_progress (std::vector<std::int64_t>& progress, int flags = 0) const;

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). Where n is the number of files, m is the number of downloading pieces and j is the number of blocks in a piece.

The flags parameter can be used to specify the granularity of the file progress. If left at the default value of 0, the progress will be as accurate as possible, but also more expensive to calculate. If torrent_handle::piece_granularity is specified, the progress will be specified in piece granularity. i.e. only pieces that have been fully downloaded and passed the hash check count. When specifying piece granularity, the operation is a lot cheaper, since libtorrent already keeps track of this internally and no calculation is required.

file_status()

std::vector<open_file_state> file_status () const;

This function returns a vector with status about files that are open for this torrent. Any file that is not open will not be reported in the vector, i.e. it's possible that the vector is empty when returning, if none of the files in the torrent are currently open.

see open_file_state

clear_error()

void clear_error () const;

If the torrent is in an error state (i.e. torrent_status::error is non-empty), this will clear the error and start the torrent again.

add_tracker() replace_trackers() trackers()

std::vector<announce_entry> trackers () const;
void replace_trackers (std::vector<announce_entry> const&) const;
void add_tracker (announce_entry const&) const;

trackers() will return the list of trackers for this torrent. The announce entry contains both a string url which specify the announce url for the tracker as well as an int tier, which is specifies the order in 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(). See announce_entry.

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.

The updated set of trackers will be saved in the resume data, and when a torrent is started with resume data, the trackers from the resume data will replace the original ones.

url_seeds() add_url_seed() remove_url_seed()

void add_url_seed (std::string const& url) const;
void remove_url_seed (std::string const& url) const;
std::set<std::string> url_seeds () const;

add_url_seed() adds another url to the torrent's list of url seeds. If the given url already exists in that list, the call has no effect. The torrent will connect to the server and try to download pieces from it, unless it's paused, queued, checking or seeding. remove_url_seed() removes the given url if it exists already. 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.

See http seeding for more information.

http_seeds() remove_http_seed() add_http_seed()

void add_http_seed (std::string const& url) const;
void remove_http_seed (std::string const& url) const;
std::set<std::string> http_seeds () const;

These functions are identical as the *_url_seed() variants, but they operate on BEP 17 web seeds instead of BEP 19.

See http seeding for more information.

add_extension()

void add_extension (
      std::function<std::shared_ptr<torrent_plugin>(torrent_handle const&, void*)> const& ext
      , void* userdata = nullptr);

add the specified extension to this torrent. The ext argument is a function that will be called from within libtorrent's context passing in the internal torrent object and the specified userdata pointer. The function is expected to return a shared pointer to a torrent_plugin instance.

set_metadata()

bool set_metadata (span<char const> metadata) const;

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 generated. If it passes, a metadata_received_alert is generated. The function returns true if the metadata is successfully set on the torrent, and false otherwise. If the torrent already has metadata, this function will not affect the torrent, and false will be returned.

is_valid()

bool is_valid () const;

Returns true if this handle refers to a valid torrent and false if it hasn't been initialized 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 that refers to that torrent will become invalid.

pause() resume()

void pause (pause_flags_t flags = {}) const;
void resume () const;

pause(), and resume() will disconnect all peers and reconnect all peers respectively. When a torrent is paused, it will however remember all share ratios to all peers and remember all potential (not connected) peers. Torrents may be paused automatically if there is a file error (e.g. disk full) or something similar. See file_error_alert.

To know if a torrent is paused or not, call torrent_handle::status() and inspect torrent_status::paused.

unset_flags() set_flags() flags()

void set_flags (torrent_flags_t flags) const;
void set_flags (torrent_flags_t flags, torrent_flags_t mask) const;
void unset_flags (torrent_flags_t flags) const;
torrent_flags_t flags () const;

sets and gets the torrent state flags. See torrent_flags_t. The set_flags overload that take a mask will affect all flags part of the mask, and set their values to what the flags argument is set to. This allows clearing and setting flags in a single function call. The set_flags overload that just takes flags, sets all the specified flags and leave any other flags unchanged. unset_flags clears the specified flags, while leaving any other flags unchanged.

flush_cache()

void flush_cache () const;

Instructs libtorrent to flush all the disk caches for this torrent and close all file handles. This is done asynchronously and you will be notified that it's complete through cache_flushed_alert.

Note that by the time you get the alert, libtorrent may have cached more data for the torrent, but you are guaranteed that whatever cached data libtorrent had by the time you called torrent_handle::flush_cache() has been written to disk.

force_recheck()

void force_recheck () const;

force_recheck puts the torrent back in a state where it assumes to have no resume data. All peers will be disconnected and the torrent will stop announcing to the tracker. The torrent will be added to the checking queue, and will be checked (all the files will be read and compared to the piece hashes). Once the check is complete, the torrent will start connecting to peers again, as normal.

save_resume_data()

void save_resume_data (resume_data_flags_t flags = {}) const;

save_resume_data() asks libtorrent to generate fast-resume data for this torrent.

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.

The fast resume data will be empty in the following cases:

1. The torrent handle is invalid.
2. The torrent hasn't received valid metadata and was started without metadata (see libtorrent's metadata from peers extension)

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.

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 the entire file.

It is still a good idea to save resume data periodically during download as well as when closing down.

Example code to pause and save resume data for all torrents and wait for the alerts:

extern int outstanding_resume_data; // global counter of outstanding resume data
std::vector<torrent_handle> handles = ses.get_torrents();
ses.pause();
for (torrent_handle const& h : handles)
{
        if (!h.is_valid()) continue;
        torrent_status s = h.status();
        if (!s.has_metadata || !s.need_save_resume_data()) continue;

        h.save_resume_data();
        ++outstanding_resume_data;
}

while (outstanding_resume_data > 0)
{
        alert const* a = ses.wait_for_alert(seconds(10));

        // if we don't get an alert within 10 seconds, abort
        if (a == nullptr) break;

        std::vector<alert*> alerts;
        ses.pop_alerts(&alerts);

        for (alert* i : alerts)
        {
                if (alert_cast<save_resume_data_failed_alert>(a))
                {
                        process_alert(a);
                        --outstanding_resume_data;
                        continue;
                }

                save_resume_data_alert const* rd = alert_cast<save_resume_data_alert>(a);
                if (rd == nullptr)
                {
                        process_alert(a);
                        continue;
                }

                torrent_handle h = rd->handle;
                torrent_status st = h.status(torrent_handle::query_save_path
                        | torrent_handle::query_name);
                std::ofstream out((st.save_path
                        + "/" + st.name + ".fastresume").c_str()
                        , std::ios_base::binary);
                out.unsetf(std::ios_base::skipws);
                bencode(std::ostream_iterator<char>(out), *rd->resume_data);
                --outstanding_resume_data;
        }
}

need_save_resume_data()

bool need_save_resume_data () const;

This function returns true if any whole chunk has been downloaded since the torrent was first loaded or since the last time the resume data was saved. When saving resume data periodically, it makes sense to skip any torrent which hasn't downloaded anything since the last time.

queue_position() queue_position_up() queue_position_bottom() queue_position_down() queue_position_top()

queue_position_t queue_position () const;
void queue_position_top () const;
void queue_position_down () const;
void queue_position_bottom () const;
void queue_position_up () const;

Every torrent that is added is assigned a queue position exactly one greater than the greatest queue position of all existing torrents. Torrents that are being seeded have -1 as their queue position, since they're no longer in line to be downloaded.

When a torrent is removed or turns into a seed, all torrents with greater queue positions have their positions decreased to fill in the space in the sequence.

queue_position() returns the torrent's position in the download queue. The torrents with the smallest numbers are the ones that are being downloaded. The smaller number, the closer the torrent is to the front of the line to be started.

The queue position is also available in the torrent_status.

The queue_position_*() functions adjust the torrents position in the queue. Up means closer to the front and down means closer to the back of the queue. Top and bottom refers to the front and the back of the queue respectively.

queue_position_set()

void queue_position_set (queue_position_t p) const;

updates the position in the queue for this torrent. The relative order of all other torrents remain intact but their numerical queue position shifts to make space for this torrent's new position

set_ssl_certificate_buffer() set_ssl_certificate()

void set_ssl_certificate (std::string const& certificate
      , std::string const& private_key
      , std::string const& dh_params
      , std::string const& passphrase = "");
void set_ssl_certificate_buffer (std::string const& certificate
      , std::string const& private_key
      , std::string const& dh_params);

For SSL torrents, use this to specify a path to a .pem file to use as this client's certificate. The certificate must be signed by the certificate in the .torrent file to be valid.

The set_ssl_certificate_buffer() overload takes the actual certificate, private key and DH params as strings, rather than paths to files.

cert is a path to the (signed) certificate in .pem format corresponding to this torrent.

private_key is a path to the private key for the specified certificate. This must be in .pem format.

dh_params is a path to the Diffie-Hellman parameter file, which needs to be in .pem format. You can generate this file using the openssl command like this: openssl dhparam -outform PEM -out dhparams.pem 512.

passphrase may be specified if the private key is encrypted and requires a passphrase to be decrypted.

Note that when a torrent first starts up, and it needs a certificate, it will suspend connecting to any peers until it has one. It's typically desirable to resume the torrent after setting the SSL certificate.

If you receive a torrent_need_cert_alert, you need to call this to provide a valid cert. If you don't have a cert you won't be allowed to connect to any peers.

get_storage_impl()

storage_interface* get_storage_impl () const;

Returns the storage implementation for this torrent. This depends on the storage constructor function that was passed to add_torrent.

torrent_file()

std::shared_ptr<const torrent_info> torrent_file () const;

Returns a pointer to the torrent_info object associated with this torrent. The torrent_info object may be a copy of the internal object. If the torrent doesn't have metadata, the pointer will not be initialized (i.e. a nullptr). The torrent may be in a state without metadata only if it was started without a .torrent file, e.g. by using the libtorrent extension of just supplying a tracker and info-hash.

piece_availability()

void piece_availability (std::vector<int>& avail) const;

Fills the specified std::vector<int> with the availability for each piece in this torrent. libtorrent does not keep track of availability for seeds, so if the torrent is seeding the availability for all pieces is reported as 0.

The piece availability is the number of peers that we are connected that has advertised having a particular piece. This is the information that libtorrent uses in order to prefer picking rare pieces.

piece_priority() prioritize_pieces() get_piece_priorities()

download_priority_t piece_priority (piece_index_t index) const;
void piece_priority (piece_index_t index, download_priority_t priority) const;
void prioritize_pieces (std::vector<std::pair<piece_index_t, download_priority_t>> const& pieces) const;
void prioritize_pieces (std::vector<download_priority_t> const& pieces) const;
std::vector<download_priority_t> get_piece_priorities () const;

These functions are used to set and get the priority of individual pieces. By default all pieces have priority 4. That means that the random rarest first algorithm is effectively active for all pieces. You may however change the priority of individual pieces. There are 8 priority levels. 0 means not to download the piece at all. Otherwise, lower priority values means less likely to be picked. Piece priority takes precedence over piece availability. Every piece with priority 7 will be attempted to be picked before a priority 6 piece and so on.

The default priority of pieces is 4.

Piece priorities can not be changed for torrents that have not downloaded the metadata yet. Magnet links won't have metadata immediately. see the metadata_received_alert.

piece_priority sets or gets the priority for an individual piece, specified by index.

prioritize_pieces takes a vector of integers, one integer per piece in the torrent. All the piece priorities will be updated with the priorities in the vector. The second overload of prioritize_pieces that takes a vector of pairs will update the priorities of only select pieces, and leave all other unaffected. Each pair is (piece, priority). That is, the first item is the piece index and the second item is the priority of that piece. Invalid entries, where the piece index or priority is out of range, are not allowed.

get_piece_priorities returns a vector with one element for each piece in the torrent. Each element is the current priority of that piece.

It's possible to cancel the effect of file priorities by setting the priorities for the affected pieces. Care has to be taken when mixing usage of file- and piece priorities.

get_file_priorities() prioritize_files() file_priority()

std::vector<download_priority_t> get_file_priorities () const;
download_priority_t file_priority (file_index_t index) const;
void file_priority (file_index_t index, download_priority_t priority) const;
void prioritize_files (std::vector<download_priority_t> const& files) const;

index must be in the range [0, number_of_files).

file_priority() queries or sets the priority of file index.

prioritize_files() takes a vector that has at as many elements as there are files in the torrent. Each entry is the priority of that file. The function sets the priorities of all the pieces in the torrent based on the vector.

get_file_priorities() returns a vector with the priorities of all files.

The priority values are the same as for piece_priority().

Whenever a file priority is changed, all other piece priorities are reset to match the file priorities. In order to maintain special priorities for particular pieces, piece_priority() has to be called again for those pieces.

You cannot set the file priorities on a torrent that does not yet have metadata or a torrent that is a seed. file_priority(int, int) and prioritize_files() are both no-ops for such torrents.

Since changing file priorities may involve disk operations (of moving files in- and out of the part file), the internal accounting of file priorities happen asynchronously. i.e. setting file priorities and then immediately querying them may not yield the same priorities just set. However, the piece priorities are updated immediately.

when combining file- and piece priorities, the resume file will record both. When loading the resume data, the file priorities will be applied first, then the piece priorities.

force_reannounce() force_dht_announce()

void force_dht_announce () const;
void force_reannounce (int seconds = 0, int tracker_index = -1, reannounce_flags_t = {}) const;

force_reannounce() will force this torrent to do another tracker request, to receive new peers. The seconds argument specifies how many seconds from now to issue the tracker announces.

If the tracker's min_interval has not passed since the last announce, the forced announce will be scheduled to happen immediately as the min_interval expires. This is to honor trackers minimum re-announce interval settings.

The tracker_index argument specifies which tracker to re-announce. If set to -1 (which is the default), all trackers are re-announce.

The flags argument can be used to affect the re-announce. See ignore_min_interval.

force_dht_announce will announce the torrent to the DHT immediately.

scrape_tracker()

void scrape_tracker (int idx = -1) const;

scrape_tracker() will send a scrape request to a tracker. By default (idx = -1) it will scrape the last working tracker. If idx is >= 0, the tracker with the specified index will scraped.

A scrape request queries the 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.

set_upload_limit() upload_limit() download_limit() set_download_limit()

int upload_limit () const;
int download_limit () const;
void set_upload_limit (int limit) const;
void set_download_limit (int limit) const;

set_upload_limit will limit the upload bandwidth used by this particular torrent to the limit you set. It is given as the number of bytes per second the torrent is allowed to upload. set_download_limit works the same way but for download bandwidth instead of upload bandwidth. Note that setting a higher limit on a torrent then the global limit (settings_pack::upload_rate_limit) will not override the global rate limit. The torrent can never upload more than the global rate limit.

upload_limit and download_limit will return the current limit setting, for upload and download, respectively.

Local peers are not rate limited by default. see peer classes.

connect_peer()

void connect_peer (tcp::endpoint const& adr, peer_source_flags_t source = {}
      , pex_flags_t flags = pex_encryption | pex_utp | pex_holepunch) const;

connect_peer() is a way to manually connect to peers that one believe is a part of the 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 system_error. The second (optional) argument will be bitwise 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.

flags are the same flags that are passed along with the ut_pex extension.

max_uploads() set_max_uploads()

int max_uploads () const;
void set_max_uploads (int max_uploads) const;

set_max_uploads() sets the maximum number of peers that's unchoked at the same time on this torrent. If you set this to -1, there will be no limit. This defaults to infinite. The primary setting controlling this is the global unchoke slots limit, set by unchoke_slots_limit in settings_pack.

max_uploads() returns the current settings.

max_connections() set_max_connections()

int max_connections () const;
void set_max_connections (int max_connections) const;

set_max_connections() sets the maximum number of connection this torrent will open. If all connections are used up, incoming connections may be refused or poor connections may be closed. This must be at least 2. The default is unlimited number of connections. If -1 is given to the function, it means unlimited. There is also a global limit of the number of connections, set by connections_limit in settings_pack.

max_connections() returns the current settings.

move_storage()

void move_storage (std::string const& save_path
      , move_flags_t flags = move_flags_t::always_replace_files
      ) const;

Moves the file(s) that this torrent are currently seeding from or downloading to. If the given save_path is not located on the same drive as the original save path, the files will be copied to the new drive and removed from their original location. This will block all other disk IO, and other torrents download and upload rates may drop while copying the file.

Since disk IO is performed in a separate thread, this operation is also asynchronous. Once the operation completes, the storage_moved_alert is generated, with the new path as the message. If the move fails for some reason, storage_moved_failed_alert is generated instead, containing the error message.

The flags argument determines the behavior of the copying/moving of the files in the torrent. see move_flags_t.

always_replace_files is the default and replaces any file that exist in both the source directory and the target directory.

fail_if_exist first check to see that none of the copy operations would cause an overwrite. If it would, it will fail. Otherwise it will proceed as if it was in always_replace_files mode. Note that there is an inherent race condition here. If the files in the target directory appear after the check but before the copy or move completes, they will be overwritten. When failing because of files already existing in the target path, the error of move_storage_failed_alert is set to boost::system::errc::file_exists.

The intention is that a client may use this as a probe, and if it fails, ask the user which mode to use. The client may then re-issue the move_storage call with one of the other modes.

dont_replace always keeps the existing file in the target directory, if there is one. The source files will still be removed in that case. Note that it won't automatically re-check files. If an incomplete torrent is moved into a directory with the complete files, pause, move, force-recheck and resume. Without the re-checking, the torrent will keep downloading and files in the new download directory will be overwritten.

Files that have been renamed to have absolute paths are not moved by this function. Keep in mind that files that don't belong to the torrent but are stored in the torrent's directory may be moved as well. This goes for files that have been renamed to absolute paths that still end up inside the save path.

rename_file()

void rename_file (file_index_t index, std::string const& new_name) const;

Renames the file with the given index asynchronously. The rename operation is complete when either a file_renamed_alert or file_rename_failed_alert is posted.

info_hash()

sha1_hash info_hash () const;

info_hash() returns the info-hash of the torrent. If this handle is to a torrent that hasn't loaded yet (for instance by being added) by a URL, the returned value is undefined.

operator!=() operator<() operator==()

bool operator!= (const torrent_handle& h) const;
bool operator< (const torrent_handle& h) const;
bool operator== (const torrent_handle& h) const;

comparison operators. The order of the torrents is unspecified but stable.

native_handle()

std::shared_ptr<torrent> native_handle () const;

This function is intended only for use by plugins and the alert dispatch function. This type does not have a stable API and should be relied on as little as possible.

enum file_progress_flags_t

Declared in "libtorrent/torrent_handle.hpp"

overwrite_existing

instruct libtorrent to overwrite any data that may already have been downloaded with the data of the new piece being added.

query_distributed_copies

calculates distributed_copies, distributed_full_copies and distributed_fraction.

query_accurate_download_counters

includes partial downloaded blocks in total_done and total_wanted_done.

query_last_seen_complete

includes last_seen_complete.

query_pieces

populate the pieces field in torrent_status.

query_verified_pieces

includes verified_pieces (only applies to torrents in seed mode).

query_torrent_file

includes torrent_file, which is all the static information from the .torrent file.

query_name

includes name, the name of the torrent. This is either derived from the .torrent file, or from the &dn= magnet link argument or possibly some other source. If the name of the torrent is not known, this is an empty string.

query_save_path

includes save_path, the path to the directory the files of the torrent are saved to.

alert_when_available

used to ask libtorrent to send an alert once the piece has been downloaded, by passing alert_when_available. When set, the read_piece_alert alert will be delivered, with the piece data, when it's downloaded.

graceful_pause clear_disk_cache

will delay the disconnect of peers that we're still downloading outstanding requests from. The torrent will not accept any more requests and will disconnect all idle peers. As soon as a peer is done transferring the blocks that were requested from it, it is disconnected. This is a graceful shut down of the torrent in the sense that no downloaded bytes are wasted.

flush_disk_cache

the disk cache will be flushed before creating the resume data. This avoids a problem with file timestamps in the resume data in case the cache hasn't been flushed yet.

save_info_dict

the resume data will contain the metadata from the torrent file as well. This is default for any torrent that's added without a torrent file (such as a magnet link or a URL).

only_if_modified

if nothing significant has changed in the torrent since the last time resume data was saved, fail this attempt. Significant changes primarily include more data having been downloaded, file or piece priorities having changed etc. If the resume data doesn't need saving, a save_resume_data_failed_alert is posted with the error resume_data_not_modified.

ignore_min_interval

by default, force-reannounce will still honor the min-interval published by the tracker. If this flag is set, it will be ignored and the tracker is announced immediately.

cache_status()

cache_status ();

initializes all counters to 0

operator==()

bool operator== (torrent_status const& st) const;

compares if the torrent status objects come from the same torrent. i.e. only the torrent_handle field is compared.

seconds()

time_duration next_announce = seconds (0);

the time until the torrent will announce itself to the tracker.

enum state_t

Declared in "libtorrent/torrent_status.hpp"

handle

a handle to the torrent whose status the object represents.

errc

may be set to an error code describing why the torrent was paused, in case it was paused by an error. If the torrent is not paused or if it's paused but not because of an error, this error_code is not set. if the error is attributed specifically to a file, error_file is set to the index of that file in the .torrent file.

error_file_none

special values for error_file to describe which file or component encountered the error (errc). the error did not occur on a file

error_file_ssl_ctx

the error occurred setting up the SSL context

error_file_exception

there was a serious error reported in this torrent. The error code or a torrent log alert may provide more information.

error_file_partfile

the error occurred with the partfile

save_path

the path to the directory where this torrent's files are stored. It's typically the path as was given to async_add_torrent() or add_torrent() when this torrent was started. This field is only included if the torrent status is queried with torrent_handle::query_save_path.

name

the name of the torrent. Typically this is derived from the .torrent file. In case the torrent was started without metadata, and hasn't completely received it yet, it returns the name given to it when added to the session. See session::add_torrent. This field is only included if the torrent status is queried with torrent_handle::query_name.

torrent_file

set to point to the torrent_info object for this torrent. It's only included if the torrent status is queried with torrent_handle::query_torrent_file.

current_tracker

the URL of the last working tracker. If no tracker request has been successful yet, it's set to an empty string.

total_download total_upload

the number of bytes downloaded and uploaded to all peers, accumulated, this session only. The session is considered to restart when a torrent is paused and restarted again. When a torrent is paused, these counters are reset to 0. If you want complete, persistent, stats, see all_time_upload and all_time_download.

total_payload_download total_payload_upload

counts the amount of bytes send and received this session, but only the actual payload data (i.e the interesting data), these counters ignore any protocol overhead. The session is considered to restart when a torrent is paused and restarted again. When a torrent is paused, these counters are reset to 0.

total_failed_bytes

the number of bytes that has been downloaded and that has failed the piece hash test. In other words, this is just how much crap that has been downloaded since the torrent was last started. If a torrent is paused and then restarted again, this counter will be reset.

total_redundant_bytes

the number of bytes that has been downloaded even though that data already was downloaded. The reason for this is that in some situations the same data can be downloaded by mistake. When libtorrent sends requests to a peer, and the peer doesn't send a response within a certain timeout, libtorrent will re-request that block. Another situation when libtorrent may re-request blocks is when the requests it sends out are not replied in FIFO-order (it will re-request blocks that are skipped by an out of order block). This is supposed to be as low as possible. This only counts bytes since the torrent was last started. If a torrent is paused and then restarted again, this counter will be reset.

pieces

a bitmask that represents which pieces we have (set to true) and the pieces we don't have. It's a pointer and may be set to 0 if the torrent isn't downloading or seeding.

verified_pieces

a bitmask representing which pieces has had their hash checked. This only applies to torrents in seed mode. If the torrent is not in seed mode, this bitmask may be empty.

total_done

the total number of bytes of the file(s) that we have. All this does not necessarily has to be downloaded during this session (that's total_payload_download).

total

the total number of bytes to download for this torrent. This may be less than the size of the torrent in case there are pad files. This number only counts bytes that will actually be requested from peers.

total_wanted_done

the number of bytes we have downloaded, only counting the pieces that we actually want to download. i.e. excluding any pieces that we have but have priority 0 (i.e. not wanted).

total_wanted

The total number of bytes we want to download. This may be smaller than the total torrent size in case any pieces are prioritized to 0, i.e. not wanted

all_time_upload all_time_download

are accumulated upload and download payload byte counters. They are saved in and restored from resume data to keep totals across sessions.

added_time

the posix-time when this torrent was added. i.e. what time(nullptr) returned at the time.

completed_time

the posix-time when this torrent was finished. If the torrent is not yet finished, this is 0.

last_seen_complete

the time when we, or one of our peers, last saw a complete copy of this torrent.

storage_mode

The allocation mode for the torrent. See storage_mode_t for the options. For more information, see storage allocation.

progress

a value in the range [0, 1], that represents the progress of the torrent's current task. It may be checking files or downloading.

progress_ppm

progress parts per million (progress * 1000000) when disabling floating point operations, this is the only option to query progress

reflects the same value as progress, but instead in a range [0, 1000000] (ppm = parts per million). When floating point operations are disabled, this is the only alternative to the floating point value in progress.

queue_position

the position this torrent has in the download queue. If the torrent is a seed or finished, this is -1.

download_rate upload_rate

the total rates for all peers for this torrent. These will usually have better precision than summing the rates from all peers. The rates are given as the number of bytes per second.

download_payload_rate upload_payload_rate

the total transfer rate of payload only, not counting protocol chatter. This might be slightly smaller than the other rates, but if projected over a long time (e.g. when calculating ETA:s) the difference may be noticeable.

num_seeds

the number of peers that are seeding that this client is currently connected to.

num_peers

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 num_incomplete

if the tracker sends scrape info in its announce reply, these fields will be set to the total number of peers that have the whole file and the total number of peers that are still downloading. set to -1 if the tracker did not send any scrape data in its announce reply.

list_seeds list_peers

the number of seeds in our peer list and the total number of peers (including seeds). We are not necessarily connected to all the peers in our peer list. This is the number of peers we know of in total, including banned peers and peers that we have failed to connect to.

connect_candidates

the number of peers in this torrent's peer list that is a candidate to be connected to. i.e. It has fewer connect attempts than the max fail count, it is not a seed if we are a seed, it is not banned etc. If this is 0, it means we don't know of any more peers that we can try.

num_pieces

the number of pieces that has been downloaded. It is equivalent to: std::accumulate(pieces->begin(), pieces->end()). So you don't have to count yourself. This can be used to see if anything has updated since last time if you want to keep a graph of the pieces up to date.

distributed_full_copies

the number of distributed copies of the torrent. Note that one copy may be spread out among many peers. It tells how many copies there are currently of the rarest piece(s) among the peers this client is connected to.

distributed_fraction

tells the share of pieces that have more copies than the rarest piece(s). Divide this number by 1000 to get the fraction.

For example, if distributed_full_copies is 2 and distributed_fraction is 500, it means that the rarest pieces have only 2 copies among the peers this torrent is connected to, and that 50% of all the pieces have more than two copies.

If we are a seed, the piece picker is deallocated as an optimization, and piece availability is no longer tracked. In this case the distributed copies members are set to -1.

distributed_copies

the number of distributed copies of the file. note that one copy may be spread out among many peers. This is a floating point representation of the distributed copies.

the integer part tells how many copies

there are of the rarest piece(s)

the fractional part tells the fraction of pieces that

have more copies than the rarest piece(s).

block_size

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 smaller, if the pieces are smaller.

num_uploads

the number of unchoked peers in this torrent.

num_connections

the number of peer connections this torrent has, including half-open connections that hasn't completed the bittorrent handshake yet. This is always >= num_peers.

uploads_limit

the set limit of upload slots (unchoked peers) for this torrent.

connections_limit

the set limit of number of connections for this torrent.

up_bandwidth_queue down_bandwidth_queue

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 limit or not. If there is no limit set on this torrent, the peers might still be waiting for bandwidth quota from the global limiter, but then they are counted in the session_status object.

seed_rank

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. Higher value means more important to seed

state

the main state the torrent is in. See torrent_status::state_t.

need_save_resume

true if this torrent has unsaved changes to its download state and statistics since the last resume data was saved.

is_seeding

true if all pieces have been downloaded.

is_finished

true if all pieces that have a priority > 0 are downloaded. There is only a distinction between finished and seeding if some pieces or files have been set to priority 0, i.e. are not downloaded.

has_metadata

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 be false is when the torrent was started torrent-less (i.e. with just an info-hash and tracker ip, a magnet link for instance).

has_incoming

true if there has ever been an incoming connection attempt to this torrent.

moving_storage

this is true if this torrent's storage is currently being moved from one location to another. This may potentially be a long operation if a large file ends up being copied from one drive to another.

announcing_to_trackers announcing_to_lsd announcing_to_dht

these are set to true if this torrent is allowed to announce to the respective peer source. Whether they are true or false is determined by the queue logic/auto manager. Torrents that are not auto managed will always be allowed to announce to all peer sources.

info_hash

the info-hash for this torrent

flags

reflects several of the torrent's flags. For more information, see torrent_handle::flags().

enum connection_type_t

Declared in "libtorrent/peer_info.hpp"

client

a string describing the software at the other end of the connection. In some cases this information is not available, then it will contain a string that may give away something about which software is running in the other end. In the case of a web seed, the server type and version will be a part of this string.

pieces

a bitfield, with one bit per piece in the torrent. Each bit tells you if the peer has that piece (if it's set to 1) or if the peer miss that piece (set to 0).

total_download total_upload

the total number of bytes downloaded from and uploaded to this peer. These numbers do not include the protocol chatter, but only the payload data.

last_request last_active

the time since we last sent a request to this peer and since any transfer occurred with this peer

download_queue_time

the time until all blocks in the request queue will be downloaded

interesting

we are interested in pieces from this peer.

choked

we have choked this peer.

remote_interested

the peer is interested in us

remote_choked

the peer has choked us.

supports_extensions

means that this peer supports the extension protocol.

local_connection

The connection was initiated by us, the peer has a listen port open, and that port is the same as in the address of this peer. If this flag is not set, this peer connection was opened by this peer connecting to us.

handshake

The connection is opened, and waiting for the handshake. Until the handshake is done, the peer cannot be identified.

connecting

The connection is in a half-open state (i.e. it is being connected).

on_parole

The peer has participated in a piece that failed the hash check, and is now "on parole", which means we're only requesting whole pieces from this peer until it either fails that piece or proves that it doesn't send bad data.

seed

This peer is a seed (it has all the pieces).

optimistic_unchoke

This peer is subject to an optimistic unchoke. It has been unchoked for a while to see if it might unchoke us in return an earn an upload/unchoke slot. If it doesn't within some period of time, it will be choked and another peer will be optimistically unchoked.

snubbed

This peer has recently failed to send a block within the request timeout from when the request was sent. We're currently picking one block at a time from this peer.

upload_only

This peer has either explicitly (with an extension) or implicitly (by becoming a seed) told us that it will not downloading anything more, regardless of which pieces we have.

endgame_mode

This means the last time this peer picket a piece, it could not pick as many as it wanted because there were not enough free ones. i.e. all pieces this peer has were already requested from other peers.

holepunched

This flag is set if the peer was in holepunch mode when the connection succeeded. This typically only happens if both peers are behind a NAT and the peers connect via the NAT holepunch mechanism.

i2p_socket

indicates that this socket is running on top of the I2P transport.

utp_socket

indicates that this socket is a uTP socket

ssl_socket

indicates that this socket is running on top of an SSL (TLS) channel

rc4_encrypted

this connection is obfuscated with RC4

plaintext_encrypted

the handshake of this connection was obfuscated with a Diffie-Hellman exchange

flags

tells you in which state the peer is in. It is set to any combination of the peer_flags_t flags above.

tracker

The peer was received from the tracker.

dht

The peer was received from the kademlia DHT.

pex

The peer was received from the peer exchange extension.

lsd

The peer was received from the local service discovery (The peer is on the local network).

resume_data

The peer was added from the fast resume data.

incoming

we received an incoming connection from this peer

source

a combination of flags describing from which sources this peer was received. A combination of the peer_source_flags_t above.

up_speed down_speed

the current upload and download speed we have to and from this peer (including any protocol messages). updated about once per second

payload_up_speed payload_down_speed

The transfer rates of payload data only updated about once per second

pid

the peer's id as used in the bit torrent protocol. This id can be used to extract 'fingerprints' from the peer. Sometimes it can tell you which client the peer is using. See identify_client()_

request_timeout

the number of seconds until the current front piece request will time out. This timeout can be adjusted through settings_pack::request_timeout. -1 means that there is not outstanding request.

send_buffer_size used_send_buffer

the number of bytes allocated and used for the peer's send buffer, respectively.

receive_buffer_size used_receive_buffer receive_buffer_watermark

the number of bytes allocated and used as receive buffer, respectively.

num_hashfails

the number of pieces this peer has participated in sending us that turned out to fail the hash check.

download_queue_length

this is the number of requests we have sent to this peer that we haven't got a response for yet

timed_out_requests

the number of block requests that have timed out, and are still in the download queue

busy_requests

the number of busy requests in the download queue. A busy request is a request for a block we've also requested from a different peer

requests_in_buffer

the number of requests messages that are currently in the send buffer waiting to be sent.

target_dl_queue_length

the number of requests that is tried to be maintained (this is typically a function of download speed)

upload_queue_length

the number of piece-requests we have received from this peer that we haven't answered with a piece yet.

failcount

the number of times this peer has "failed". i.e. failed to connect or disconnected us. The failcount is decremented when we see this peer in a tracker response or peer exchange message.

downloading_piece_index downloading_block_index downloading_progress downloading_total

You can know which piece, and which part of that piece, that is currently being downloaded from a specific peer by looking at these four members. downloading_piece_index is the index of the piece that is currently being downloaded. This may be set to -1 if there's currently no piece downloading from this peer. If it is >= 0, the other three members are valid. downloading_block_index is the index of the block (or sub-piece) that is being downloaded. downloading_progress is the number of bytes of this block we have received from the peer, and downloading_total is the total number of bytes in this block.

connection_type

the kind of connection this peer uses. See connection_type_t.

pending_disk_bytes

the number of bytes this peer has pending in the disk-io thread. Downloaded and waiting to be written to disk. This is what is capped by settings_pack::max_queued_disk_bytes.

pending_disk_read_bytes

number of outstanding bytes to read from disk

send_quota receive_quota

the number of bytes this peer has been assigned to be allowed to send and receive until it has to request more quota from the bandwidth manager.

rtt

an estimated round trip time to this peer, in milliseconds. It is estimated by timing the the TCP connect(). It may be 0 for incoming connections.

num_pieces

the number of pieces this peer has.

download_rate_peak upload_rate_peak

the highest download and upload rates seen on this connection. They are given in bytes per second. This number is reset to 0 on reconnect.

progress

the progress of the peer in the range [0, 1]. This is always 0 when floating point operations are disabled, instead use progress_ppm.

progress_ppm

indicates the download progress of the peer in the range [0, 1000000] (parts per million).

estimated_reciprocation_rate

this is an estimation of the upload rate, to this peer, where it will unchoke us. This is a coarse estimation based on the rate at which we sent right before we were choked. This is primarily used for the bittyrant choking algorithm.

ip

the IP-address to this peer. The type is an asio endpoint. For more info, see the asio documentation.

local_endpoint

the IP and port pair the socket is bound to locally. i.e. the IP address of the interface it's going out over. This may be useful for multi-homed clients with multiple interfaces to the internet.

bw_idle

The peer is not waiting for any external events to send or receive data.

bw_limit

The peer is waiting for the rate limiter.

bw_network

The peer has quota and is currently waiting for a network read or write operation to complete. This is the state all peers are in if there are no bandwidth limits.

bw_disk

The peer is waiting for the disk I/O thread to catch up writing buffers to disk before downloading more.

read_state write_state

bitmasks indicating what state this peer is in with regards to sending and receiving data. The states are declared in the bw_state enum.

load_state() save_state()

void load_state (bdecode_node const& e, save_state_flags_t flags = save_state_flags_t::all());
void save_state (entry& e, save_state_flags_t flags = save_state_flags_t::all()) const;

TODO: 2 the ip filter should probably be saved here too loads and saves all session settings, including dht_settings, encryption settings and proxy settings. save_state writes all keys to the entry that's passed in, which needs to either not be initialized, or initialized as a dictionary.

load_state expects a bdecode_node which can be built from a bencoded buffer with bdecode().

The flags argument is used to filter which parts of the session state to save or load. By default, all state is saved/restored (except for the individual torrents).

When saving settings, there are two fields that are not loaded. peer_fingerprint and user_agent. Those are left as configured by the session_settings passed to the session constructor or subsequently set via apply_settings().

get_torrent_status() refresh_torrent_status()

void refresh_torrent_status (std::vector<torrent_status>* ret
      , status_flags_t flags = {}) const;
std::vector<torrent_status> get_torrent_status (
      std::function<bool(torrent_status const&)> const& pred
      , status_flags_t flags = {}) const;

get_torrent_status returns a vector of the torrent_status for every torrent which satisfies pred, which is a predicate function which determines if a torrent should be included in the returned set or not. Returning true means it should be included and false means excluded. The flags argument is the same as to torrent_handle::status(). Since pred is guaranteed to be called for every torrent, it may be used to count the number of torrents of different categories as well.

refresh_torrent_status takes a vector of torrent_status structs (for instance the same vector that was returned by get_torrent_status() ) and refreshes the status based on the handle member. It is possible to use this function by first setting up a vector of default constructed torrent_status objects, only initializing the handle member, in order to request the torrent status for multiple torrents in a single call. This can save a significant amount of time if you have a lot of torrents.

Any torrent_status object whose handle member is not referring to a valid torrent are ignored.

post_torrent_updates()

void post_torrent_updates (status_flags_t flags = status_flags_t::all());

This functions instructs the session to post the state_update_alert, containing the status of all torrents whose state changed since the last time this function was called.

Only torrents who has the state subscription flag set will be included. This flag is on by default. See add_torrent_params. the flags argument is the same as for torrent_handle::status(). see torrent_handle::status_flags_t.

post_session_stats()

void post_session_stats ();

This function will post a session_stats_alert object, containing a snapshot of the performance counters from the internals of libtorrent. To interpret these counters, query the session via session_stats_metrics().

For more information, see the session statistics section.

post_dht_stats()

void post_dht_stats ();

This will cause a dht_stats_alert to be posted.

find_torrent() get_torrents()

torrent_handle find_torrent (sha1_hash const& info_hash) const;
std::vector<torrent_handle> get_torrents () const;

find_torrent() looks for a torrent with the given info-hash. In case there is such a torrent in the session, a torrent_handle to that torrent is returned. In case the torrent cannot be found, an invalid torrent_handle is returned.

See torrent_handle::is_valid() to know if the torrent was found or not.

get_torrents() returns a vector of torrent_handles to all the torrents currently in the session.

add_torrent() async_add_torrent()

void async_add_torrent (add_torrent_params&& params);
torrent_handle add_torrent (add_torrent_params const& params);
torrent_handle add_torrent (add_torrent_params&& params);
void async_add_torrent (add_torrent_params const& params);
torrent_handle add_torrent (add_torrent_params const& params, error_code& ec);
torrent_handle add_torrent (add_torrent_params&& params, error_code& ec);

You add torrents through the add_torrent() function where you give an object with all the parameters. The add_torrent() overloads will block until the torrent has been added (or failed to be added) and returns an error code and a torrent_handle. In order to add torrents more efficiently, consider using async_add_torrent() which returns immediately, without waiting for the torrent to add. Notification of the torrent being added is sent as add_torrent_alert.

The overload that does not take an error_code throws an exception on error and is not available when building without exception support. 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.

If the torrent you are trying to add already exists in the session (is either queued for checking, being checked or downloading) add_torrent() will throw system_error 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.

all torrent_handles must be destructed before the session is destructed!

pause() resume() is_paused()

void resume ();
void pause ();
bool is_paused () const;

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.

get_cache_info()

void get_cache_info (cache_status* ret, torrent_handle h = torrent_handle(), int flags = 0) const;

Fills in the cache_status struct with information about the given torrent. If flags is session::disk_cache_no_pieces the cache_status::pieces field will not be set. This may significantly reduce the cost of this call.

get_dht_settings() is_dht_running() set_dht_settings()

bool is_dht_running () const;
void set_dht_settings (dht::dht_settings const& settings);
dht::dht_settings get_dht_settings () const;

set_dht_settings sets some parameters available to the dht node. See dht_settings for more information.

is_dht_running() returns true if the DHT support has been started and false otherwise.

get_dht_settings() returns the current settings

set_dht_storage()

void set_dht_storage (dht::dht_storage_constructor_type sc);

set_dht_storage set a dht custom storage constructor function to be used internally when the dht is created.

Since the dht storage is a critical component for the dht behavior, this function will only be effective the next time the dht is started. If you never touch this feature, a default map-memory based storage is used.

If you want to make sure the dht is initially created with your custom storage, create a session with the setting settings_pack::enable_dht to false, set your constructor function and call apply_settings with settings_pack::enable_dht to true.

add_dht_node()

void add_dht_node (std::pair<std::string, int> const& node);

add_dht_node takes a host name and port pair. That endpoint will be pinged, and if a valid DHT reply is received, the node will be added to the routing table.

dht_get_item()

void dht_get_item (sha1_hash const& target);

query the DHT for an immutable item at the target hash. the result is posted as a dht_immutable_item_alert.

dht_get_item()

void dht_get_item (std::array<char, 32> key
      , std::string salt = std::string());

query the DHT for a mutable item under the public key key. this is an ed25519 key. salt is optional and may be left as an empty string if no salt is to be used. if the item is found in the DHT, a dht_mutable_item_alert is posted.

dht_put_item()

sha1_hash dht_put_item (entry data);

store the given bencoded data as an immutable item in the DHT. the returned hash is the key that is to be used to look the item up again. It's just the SHA-1 hash of the bencoded form of the structure.

dht_put_item()

void dht_put_item (std::array<char, 32> key
      , std::function<void(entry&, std::array<char, 64>&
      , std::int64_t&, std::string const&)> cb
      , std::string salt = std::string());

store a mutable item. The key is the public key the blob is to be stored under. The optional salt argument is a string that is to be mixed in with the key when determining where in the DHT the value is to be stored. The callback function is called from within the libtorrent network thread once we've found where to store the blob, possibly with the current value stored under the key. The values passed to the callback functions are:

entry& value

the current value stored under the key (may be empty). Also expected to be set to the value to be stored by the function.

std::array<char,64>& signature

the signature authenticating the current value. This may be zeros if there is currently no value stored. The function is expected to fill in this buffer with the signature of the new value to store. To generate the signature, you may want to use the sign_mutable_item function.

std::int64_t& seq

current sequence number. May be zero if there is no current value. The function is expected to set this to the new sequence number of the value that is to be stored. Sequence numbers must be monotonically increasing. Attempting to overwrite a value with a lower or equal sequence number will fail, even if the signature is correct.

std::string const& salt

this is the salt that was used for this put call.

Since the callback function cb is called from within libtorrent, it is critical to not perform any blocking operations. Ideally not even locking a mutex. Pass any data required for this function along with the function object's context and make the function entirely self-contained. The only reason data blob's value is computed via a function instead of just passing in the new value is to avoid race conditions. If you want to update the value in the DHT, you must first retrieve it, then modify it, then write it back. The way the DHT works, it is natural to always do a lookup before storing and calling the callback in between is convenient.

dht_live_nodes()

void dht_live_nodes (sha1_hash const& nid);

Retrieve all the live DHT (identified by nid) nodes. All the nodes id and endpoint will be returned in the list of nodes in the alert dht_live_nodes_alert. Since this alert is a response to an explicit call, it will always be posted, regardless of the alert mask.

dht_sample_infohashes()

void dht_sample_infohashes (udp::endpoint const& ep, sha1_hash const& target);

Query the DHT node specified by ep to retrieve a sample of the info-hashes that the node currently have in their storage. The target is included for iterative lookups so that indexing nodes can perform a key space traversal with a single RPC per node by adjusting the target value for each RPC. It has no effect on the returned sample value. The result is posted as a dht_sample_infohashes_alert.

dht_direct_request()

void dht_direct_request (udp::endpoint const& ep, entry const& e, void* userdata = nullptr);

Send an arbitrary DHT request directly to the specified endpoint. This function is intended for use by plugins. When a response is received or the request times out, a dht_direct_response_alert will be posted with the response (if any) and the userdata pointer passed in here. Since this alert is a response to an explicit call, it will always be posted, regardless of the alert mask.

add_extension()

void add_extension (std::function<std::shared_ptr<torrent_plugin>(
      torrent_handle const&, void*)> ext);
void add_extension (std::shared_ptr<plugin> ext);

This function adds an extension to this session. The argument is a function object that is called with a torrent_handle and which should return a std::shared_ptr<torrent_plugin>. To write custom plugins, see libtorrent plugins. For the typical bittorrent client all of these extensions should be added. The main plugins implemented in libtorrent are:

uTorrent metadata

Allows peers to download the metadata (.torrent files) from the swarm directly. Makes it possible to join a swarm with just a tracker and info-hash.

#include <libtorrent/extensions/ut_metadata.hpp>
ses.add_extension(&libtorrent::create_ut_metadata_plugin);

uTorrent peer exchange

Exchanges peers between clients.

#include <libtorrent/extensions/ut_pex.hpp>
ses.add_extension(&libtorrent::create_ut_pex_plugin);

smart ban plugin

A plugin that, with a small overhead, can ban peers that sends bad data with very high accuracy. Should eliminate most problems on poisoned torrents.

#include <libtorrent/extensions/smart_ban.hpp>
ses.add_extension(&libtorrent::create_smart_ban_plugin);

get_ip_filter() set_ip_filter()

ip_filter get_ip_filter () const;
void set_ip_filter (ip_filter const& f);

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 generated. get_ip_filter() Returns the ip_filter currently in the session. See ip_filter.

set_port_filter()

void set_port_filter (port_filter const& f);

apply port_filter f to incoming and outgoing peers. a port filter will reject making outgoing peer connections to certain remote ports. The main intention is to be able to avoid triggering certain anti-virus software by connecting to SMTP, FTP ports.

listen_port() ssl_listen_port() is_listening()

bool is_listening () const;
unsigned short listen_port () const;
unsigned short ssl_listen_port () const;

is_listening() will tell you whether or not the session has successfully opened a listening port. If it hasn't, this function will return false, and then you can set a new settings_pack::listen_interfaces to try another interface and port to bind to.

listen_port() returns the port we ended up listening on.

get_peer_class_filter() set_peer_class_filter()

ip_filter get_peer_class_filter () const;
void set_peer_class_filter (ip_filter const& f);

Sets the peer class filter for this session. All new peer connections will take this into account and be added to the peer classes specified by this filter, based on the peer's IP address.

The ip-filter essentially maps an IP -> uint32. Each bit in that 32 bit integer represents a peer class. The least significant bit represents class 0, the next bit class 1 and so on.

For more info, see ip_filter.

For example, to make all peers in the range 200.1.1.0 - 200.1.255.255 belong to their own peer class, apply the following filter:

ip_filter f = ses.get_peer_class_filter();
peer_class_t my_class = ses.create_peer_class("200.1.x.x IP range");
f.add_rule(make_address("200.1.1.0"), make_address("200.1.255.255")
        , 1 << static_cast<std::uint32_t>(my_class));
ses.set_peer_class_filter(f);

This setting only applies to new connections, it won't affect existing peer connections.

This function is limited to only peer class 0-31, since there are only 32 bits in the IP range mapping. Only the set bits matter; no peer class will be removed from a peer as a result of this call, peer classes are only added.

The peer_class argument cannot be greater than 31. The bitmasks representing peer classes in the peer_class_filter are 32 bits.

The get_peer_class_filter() function returns the current filter.

For more information, see peer classes.

set_peer_class_type_filter() get_peer_class_type_filter()

void set_peer_class_type_filter (peer_class_type_filter const& f);
peer_class_type_filter get_peer_class_type_filter () const;

Sets and gets the peer class type filter. This is controls automatic peer class assignments to peers based on what kind of socket it is.

It does not only support assigning peer classes, it also supports removing peer classes based on socket type.

The order of these rules being applied are:

1. peer-class IP filter
2. peer-class type filter, removing classes
3. peer-class type filter, adding classes

For more information, see peer classes.

create_peer_class()

peer_class_t create_peer_class (char const* name);

Creates a new peer class (see peer classes) with the given name. The returned integer is the new peer class identifier. Peer classes may have the same name, so each invocation of this function creates a new class and returns a unique identifier.

Identifiers are assigned from low numbers to higher. So if you plan on using certain peer classes in a call to set_peer_class_filter(), make sure to create those early on, to get low identifiers.

For more information on peer classes, see peer classes.

delete_peer_class()

void delete_peer_class (peer_class_t cid);

This call dereferences the reference count of the specified peer class. When creating a peer class it's automatically referenced by 1. If you want to recycle a peer class, you may call this function. You may only call this function once per peer class you create. Calling it more than once for the same class will lead to memory corruption.

Since peer classes are reference counted, this function will not remove the peer class if it's still assigned to torrents or peers. It will however remove it once the last peer and torrent drops their references to it.

There is no need to call this function for custom peer classes. All peer classes will be properly destructed when the session object destructs.

For more information on peer classes, see peer classes.

get_peer_class() set_peer_class()

peer_class_info get_peer_class (peer_class_t cid) const;
void set_peer_class (peer_class_t cid, peer_class_info const& pci);

These functions queries information from a peer class and updates the configuration of a peer class, respectively.

cid must refer to an existing peer class. If it does not, the return value of get_peer_class() is undefined.

set_peer_class() sets all the information in the peer_class_info object in the specified peer class. There is no option to only update a single property.

A peer or torrent belonging to more than one class, the highest priority among any of its classes is the one that is taken into account.

For more information, see peer classes.

remove_torrent()

void remove_torrent (const torrent_handle& h, remove_flags_t options = {});

remove_torrent() will close all peer connections associated with the torrent and tell the tracker that we've stopped participating in the swarm. This operation cannot fail. When it completes, you will receive a torrent_removed_alert.

The optional second argument options can be used to delete all the files downloaded by this torrent. To do so, pass in the value session_handle::delete_files. The removal of the torrent is asynchronous, there is no guarantee that adding the same torrent immediately after it was removed will not throw a system_error exception. Once the torrent is deleted, a torrent_deleted_alert is posted.

Note that when a queued or downloading torrent is removed, its position in the download queue is vacated and every subsequent torrent in the queue has their queue positions updated. This can potentially cause a large state_update to be posted. When removing all torrents, it is advised to remove them from the back of the queue, to minimize the shifting.

get_settings() apply_settings()

void apply_settings (settings_pack&& s);
settings_pack get_settings () const;
void apply_settings (settings_pack const& s);

Applies the settings specified by the settings_pack s. This is an asynchronous operation that will return immediately and actually apply the settings to the main thread of libtorrent some time later.

pop_alerts() wait_for_alert() set_alert_notify()

void pop_alerts (std::vector<alert*>* alerts);
void set_alert_notify (std::function<void()> const& fun);
alert* wait_for_alert (time_duration max_wait);

Alerts is the main mechanism for libtorrent to report errors and events. pop_alerts fills in the vector passed to it with pointers to new alerts. The session still owns these alerts and they will stay valid until the next time pop_alerts is called. You may not delete the alert objects.

It is safe to call pop_alerts from multiple different threads, as long as the alerts themselves are not accessed once another thread calls pop_alerts. Doing this requires manual synchronization between the popping threads.

wait_for_alert will block the current thread for max_wait time duration, or until another alert is posted. If an alert is available at the time of the call, it returns immediately. The returned alert pointer is the head of the alert queue. wait_for_alert does not pop alerts from the queue, it merely peeks at it. The returned alert will stay valid until pop_alerts is called twice. The first time will pop it and the second will free it.

If there is no alert in the queue and no alert arrives within the specified timeout, wait_for_alert returns nullptr.

In the python binding, wait_for_alert takes the number of milliseconds to wait as an integer.

The alert queue in the session will not grow indefinitely. Make sure to pop periodically to not miss notifications. To control the max number of alerts that's queued by the session, see settings_pack::alert_queue_size.

Some alerts are considered so important that they are posted even when the alert queue is full. Some alerts are considered mandatory and cannot be disabled by the alert_mask. For instance, save_resume_data_alert and save_resume_data_failed_alert are always posted, regardless of the alert mask.

To control which alerts are posted, set the alert_mask (settings_pack::alert_mask).

the set_alert_notify function lets the client set a function object to be invoked every time the alert queue goes from having 0 alerts to 1 alert. This function is called from within libtorrent, it may be the main thread, or it may be from within a user call. The intention of of the function is that the client wakes up its main thread, to poll for more alerts using pop_alerts(). If the notify function fails to do so, it won't be called again, until pop_alerts is called for some other reason. For instance, it could signal an eventfd, post a message to an HWND or some other main message pump. The actual retrieval of alerts should not be done in the callback. In fact, the callback should not block. It should not perform any expensive work. It really should just notify the main application thread.

The type of an alert is returned by the polymorphic function alert::type() but can also be queries from a concrete type via T::alert_type, as a static constant.

add_port_mapping() delete_port_mapping()

void delete_port_mapping (port_mapping_t handle);
std::vector<port_mapping_t> add_port_mapping (portmap_protocol t, int external_port, int local_port);

add_port_mapping adds a port forwarding on UPnP and/or NAT-PMP, whichever is enabled. The return value is a handle referring to the port mapping that was just created. Pass it to delete_port_mapping() to remove it.

reopen_network_sockets()

void reopen_network_sockets (reopen_network_flags_t options = reopen_map_ports);

Instructs the session to reopen all listen and outgoing sockets.

It's useful in the case your platform doesn't support the built in IP notifier mechanism, or if you have a better more reliable way to detect changes in the IP routing table.

native_handle()

std::shared_ptr<aux::session_impl> native_handle () const;

This function is intended only for use by plugins. This type does not have a stable API and should be relied on as little as possible.

save_settings

saves settings (i.e. the settings_pack)

save_dht_settings

saves dht_settings

save_dht_state

saves dht state such as nodes and node-id, possibly accelerating joining the DHT if provided at next session startup.

global_peer_class_id tcp_peer_class_id local_peer_class_id

built-in peer classes

delete_files

delete the files belonging to the torrent from disk. including the part-file, if there is one

delete_partfile

delete just the part-file associated with this torrent

add_default_plugins

this will add common extensions like ut_pex, ut_metadata, lt_tex smart_ban and possibly others.

udp tcp

protocols used by add_port_mapping()

reopen_map_ports

This option indicates if the ports are mapped using natpmp and upnp. If mapping was already made, they are deleted and added again. This only works if natpmp and/or upnp are configured to be enable.

add_torrent_params() operator=()

add_torrent_params (add_torrent_params&&) noexcept;
add_torrent_params& operator= (add_torrent_params const&);
explicit add_torrent_params (storage_constructor_type sc = default_storage_constructor);
add_torrent_params& operator= (add_torrent_params&&) = default;
add_torrent_params (add_torrent_params const&);

The constructor can be used to initialize the storage constructor, which determines the storage mechanism for the downloaded or seeding data for the torrent. For more information, see the storage field.

version

filled in by the constructor and should be left untouched. It is used for forward binary compatibility.

ti

torrent_info object with the torrent to add. Unless the info_hash is set, this is required to be initialized.

trackers

If the torrent doesn't have a tracker, but relies on the DHT to find peers, the trackers can specify tracker URLs for the torrent.

tracker_tiers

the tiers the URLs in trackers belong to. Trackers belonging to different tiers may be treated differently, as defined by the multi tracker extension. This is optional, if not specified trackers are assumed to be part of tier 0, or whichever the last tier was as iterating over the trackers.

dht_nodes

a list of hostname and port pairs, representing DHT nodes to be added to the session (if DHT is enabled). The hostname may be an IP address.

save_path

the path where the torrent is or will be stored.

Note

On windows this path (and other paths) are interpreted as UNC paths. This means they must use backslashes as directory separators and may not contain the special directories "." or "..".

Setting this to an absolute path performs slightly better than a relative path.

storage_mode

One of the values from storage_mode_t. For more information, see storage allocation.

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.

userdata

The userdata parameter is optional and will be passed on to the extension constructor functions, if any (see torrent_handle::add_extension()).

file_priorities

can be set to control the initial file priorities when adding a torrent. The semantics are the same as for torrent_handle::prioritize_files(). The file priorities specified in here take precedence over those specified in the resume data, if any.

trackerid

the default tracker id to be used when announcing to trackers. By default this is empty, and no tracker ID is used, since this is an optional argument. If a tracker returns a tracker ID, that ID is used instead of this.

flags

flags controlling aspects of this torrent and how it's added. See torrent_flags_t for details.

Note

The flags field is initialized with default flags by the constructor. In order to preserve default behavior when clearing or setting other flags, make sure to bitwise OR or in a flag or bitwise AND the inverse of a flag to clear it.

info_hash

set this to the info hash of the torrent to add in case the info-hash is the only known property of the torrent. i.e. you don't have a .torrent file nor a magnet link. To add a magnet link, use parse_magnet_uri() to populate fields in the add_torrent_params object.

max_uploads max_connections

max_uploads, max_connections, upload_limit, download_limit correspond to the set_max_uploads(), set_max_connections(), set_upload_limit() and set_download_limit() functions on torrent_handle. These values let you initialize these settings when the torrent is added, instead of calling these functions immediately following adding it.

-1 means unlimited on these settings just like their counterpart functions on torrent_handle

For fine grained control over rate limits, including making them apply to local peers, see peer classes.

total_uploaded total_downloaded

the total number of bytes uploaded and downloaded by this torrent so far.

active_time finished_time seeding_time

the number of seconds this torrent has spent in started, finished and seeding state so far, respectively.

added_time completed_time

if set to a non-zero value, this is the posix time of when this torrent was first added, including previous runs/sessions. If set to zero, the internal added_time will be set to the time of when add_torrent() is called.

last_seen_complete

if set to non-zero, initializes the time (expressed in posix time) when we last saw a seed or peers that together formed a complete copy of the torrent. If left set to zero, the internal counterpart to this field will be updated when we see a seed or a distributed copies >= 1.0.

num_complete num_incomplete

these field can be used to initialize the torrent's cached scrape data. The scrape data is high level metadata about the current state of the swarm, as returned by the tracker (either when announcing to it or by sending a specific scrape request). num_complete is the number of peers in the swarm that are seeds, or have every piece in the torrent. num_incomplete is the number of peers in the swarm that do not have every piece. num_downloaded is the number of times the torrent has been downloaded (not initiated, but the number of times a download has completed).

Leaving any of these values set to -1 indicates we don't know, or we have not received any scrape data.

http_seeds url_seeds

URLs can be added to these two lists to specify additional web seeds to be used by the torrent. If the flag_override_web_seeds is set, these will be the _only_ ones to be used. i.e. any web seeds found in the .torrent file will be overridden.

http_seeds expects URLs to web servers implementing the original HTTP seed specification BEP 17.

url_seeds expects URLs to regular web servers, aka "get right" style, specified in BEP 19.

peers

peers to add to the torrent, to be tried to be connected to as bittorrent peers.

banned_peers

peers banned from this torrent. The will not be connected to

unfinished_pieces

this is a map of partially downloaded piece. The key is the piece index and the value is a bitfield where each bit represents a 16 kiB block. A set bit means we have that block.

have_pieces

this is a bitfield indicating which pieces we already have of this torrent.

verified_pieces

when in seed_mode, pieces with a set bit in this bitfield have been verified to be valid. Other pieces will be verified the first time a peer requests it.

piece_priorities

this sets the priorities for each individual piece in the torrent. Each element in the vector represent the piece with the same index. If you set both file- and piece priorities, file priorities will take precedence.

merkle_tree

if this is a merkle tree torrent, and you're seeding, this field must be set. It is all the hashes in the binary tree, with the root as the first entry. See torrent_info::set_merkle_tree() for more info.

renamed_files

this is a map of file indices in the torrent and new filenames to be applied before the torrent is added.

remove() add()

void add (socket_type_t const st, peer_class_t const peer_class);
void remove (socket_type_t const st, peer_class_t const peer_class);

add() and remove() adds and removes a peer class to be added to new peers based on socket type.

disallow() allow()

void allow (socket_type_t const st, peer_class_t const peer_class);
void disallow (socket_type_t const st, peer_class_t const peer_class);

disallow() and allow() adds and removes a peer class to be removed from new peers based on socket type.

The peer_class argument cannot be greater than 31. The bitmasks representing peer classes in the peer_class_type_filter are 32 bits.

apply()

std::uint32_t apply (socket_type_t const st, std::uint32_t peer_class_mask);

takes a bitmask of peer classes and returns a new bitmask of peer classes after the rules have been applied, based on the socket type argument (st).

enum socket_type_t : std::uint8_t

Declared in "libtorrent/peer_class_type_filter.hpp"

reset()

void reset ();

This member function set the counters to zero.

update_node_ids()

virtual void update_node_ids (std::vector<node_id> const& ids) = 0;

This member function notifies the list of all node's ids of each DHT running inside libtorrent. It's advisable that the concrete implementation keeps a copy of this list for an eventual prioritization when deleting an element to make room for a new one.

get_peers()

virtual bool get_peers (sha1_hash const& info_hash
      , bool noseed, bool scrape, address const& requester
      , entry& peers) const = 0;

This function retrieve the peers tracked by the DHT corresponding to the given info_hash. You can specify if you want only seeds and/or you are scraping the data.

For future implementers: If the torrent tracked contains a name, such a name must be stored as a string in peers["n"]

If the scrape parameter is true, you should fill these keys:

peers["BFpe"] - with the standard bit representation of a

256 bloom filter containing the downloaders

peers["BFsd"] - with the standard bit representation of a

256 bloom filter containing the seeders

If the scrape parameter is false, you should fill the key peers["values"] with a list containing a subset of peers tracked by the given info_hash. Such a list should consider the value of dht_settings::max_peers_reply. If noseed is true only peers marked as no seed should be included.

returns true if the maximum number of peers are stored for this info_hash.

announce_peer()

virtual void announce_peer (sha1_hash const& info_hash
      , tcp::endpoint const& endp
      , string_view name, bool seed) = 0;

This function is named announce_peer for consistency with the upper layers, but has nothing to do with networking. Its only responsibility is store the peer in such a way that it's returned in the entry with the lookup_peers.

The name parameter is the name of the torrent if provided in the announce_peer DHT message. The length of this value should have a maximum length in the final storage. The default implementation truncate the value for a maximum of 50 characters.

get_immutable_item()

virtual bool get_immutable_item (sha1_hash const& target
      , entry& item) const = 0;

This function retrieves the immutable item given its target hash.

For future implementers: The value should be returned as an entry in the key item["v"].

returns true if the item is found and the data is returned inside the (entry) out parameter item.

put_immutable_item()

virtual void put_immutable_item (sha1_hash const& target
      , span<char const> buf
      , address const& addr) = 0;

Store the item's data. This layer is only for storage. The authentication of the item is performed by the upper layer.

For implementers: This data can be stored only if the target is not already present. The implementation should consider the value of dht_settings::max_dht_items.

get_mutable_item_seq()

virtual bool get_mutable_item_seq (sha1_hash const& target
      , sequence_number& seq) const = 0;

This function retrieves the sequence number of a mutable item.

returns true if the item is found and the data is returned inside the out parameter seq.

get_mutable_item()

virtual bool get_mutable_item (sha1_hash const& target
      , sequence_number seq, bool force_fill
      , entry& item) const = 0;

This function retrieves the mutable stored in the DHT.

For implementers: The item sequence should be stored in the key item["seq"]. if force_fill is true or (0 <= seq and seq < item["seq"]) the following keys should be filled item["v"] - with the value no encoded. item["sig"] - with a string representation of the signature. item["k"] - with a string representation of the public key.

returns true if the item is found and the data is returned inside the (entry) out parameter item.

put_mutable_item()

virtual void put_mutable_item (sha1_hash const& target
      , span<char const> buf
      , signature const& sig
      , sequence_number seq
      , public_key const& pk
      , span<char const> salt
      , address const& addr) = 0;

Store the item's data. This layer is only for storage. The authentication of the item is performed by the upper layer.

For implementers: The sequence number should be checked if the item is already present. The implementation should consider the value of dht_settings::max_dht_items.

get_infohashes_sample()

virtual int get_infohashes_sample (entry& item) = 0;

This function retrieves a sample info-hashes

For implementers: The info-hashes should be stored in ["samples"] (N × 20 bytes). the following keys should be filled item["interval"] - the subset refresh interval in seconds. item["num"] - number of info-hashes in storage.

Internally, this function is allowed to lazily evaluate, cache and modify the actual sample to put in item

returns the number of info-hashes in the sample.

tick()

virtual void tick () = 0;

This function is called periodically (non-constant frequency).

For implementers: Use this functions for expire peers or items or any other storage cleanup.

implemented_features()

virtual feature_flags_t implemented_features ();

This function is expected to return a bitmask indicating which features this plugin implements. Some callbacks on this object may not be called unless the corresponding feature flag is returned here. Note that callbacks may still be called even if the corresponding feature is not specified in the return value here. See feature_flags_t for possible flags to return.

new_torrent()

virtual std::shared_ptr<torrent_plugin> new_torrent (torrent_handle const&, void*);

this is called by the session every time a new torrent is added. The torrent* points to the internal torrent object created for the new torrent. The void* is the userdata pointer as passed in via add_torrent_params.

If the plugin returns a torrent_plugin instance, it will be added to the new torrent. Otherwise, return an empty shared_ptr to a torrent_plugin (the default).

added()

virtual void added (session_handle const&);

called when plugin is added to a session

on_dht_request()

virtual bool on_dht_request (string_view /* query */
      , udp::endpoint const& /* source */, bdecode_node const& /* message */
      , entry& /* response */);

called when a dht request is received. If your plugin expects this to be called, make sure to include the flag dht_request_feature in the return value from implemented_features().

on_alert()

virtual void on_alert (alert const*);

called when an alert is posted alerts that are filtered are not posted. If your plugin expects this to be called, make sure to include the flag alert_feature in the return value from implemented_features().

on_unknown_torrent()

virtual bool on_unknown_torrent (sha1_hash const& /* info_hash */
      , peer_connection_handle const& /* pc */, add_torrent_params& /* p */);

return true if the add_torrent_params should be added

on_tick()

virtual void on_tick ();

called once per second. If your plugin expects this to be called, make sure to include the flag tick_feature in the return value from implemented_features().

get_unchoke_priority()

virtual uint64_t get_unchoke_priority (peer_connection_handle const& /* peer */);

called when choosing peers to optimistically unchoke. The return value indicates the peer's priority for unchoking. Lower return values correspond to higher priority. Priorities above 2^63-1 are reserved. If your plugin has no priority to assign a peer it should return 2^64-1. If your plugin expects this to be called, make sure to include the flag optimistic_unchoke_feature in the return value from implemented_features(). If multiple plugins implement this function the lowest return value (i.e. the highest priority) is used.

save_state()

virtual void save_state (entry&);

called when saving settings state

load_state()

virtual void load_state (bdecode_node const&);

called when loading settings state

optimistic_unchoke_feature

include this bit if your plugin needs to alter the order of the optimistic unchoke of peers. i.e. have the on_optimistic_unchoke() callback be called.

tick_feature

include this bit if your plugin needs to have on_tick() called

dht_request_feature

include this bit if your plugin needs to have on_dht_request() called

alert_feature

include this bit if your plugin needs to have on_alert() called

new_connection()

virtual std::shared_ptr<peer_plugin> new_connection (peer_connection_handle const&);

This function is called each time a new peer is connected to the torrent. You may choose to ignore this by just returning a default constructed shared_ptr (in which case you don't need to override this member function).

If you need an extension to the peer connection (which most plugins do) you are supposed to return an instance of your peer_plugin class. Which in turn will have its hook functions called on event specific to that peer.

The peer_connection_handle will be valid as long as the shared_ptr is being held by the torrent object. So, it is generally a good idea to not keep a shared_ptr to your own peer_plugin. If you want to keep references to it, use weak_ptr.

If this function throws an exception, the connection will be closed.

on_piece_failed() on_piece_pass()

virtual void on_piece_failed (piece_index_t);
virtual void on_piece_pass (piece_index_t);

These hooks are called when a piece passes the hash check or fails the hash check, respectively. The index is the piece index that was downloaded. It is possible to access the list of peers that participated in sending the piece through the torrent and the piece_picker.

tick()

virtual void tick ();

This hook is called approximately once per second. It is a way of making it easy for plugins to do timed events, for sending messages or whatever.

on_resume() on_pause()

virtual bool on_resume ();
virtual bool on_pause ();

These hooks are called when the torrent is paused and resumed respectively. The return value indicates if the event was handled. A return value of true indicates that it was handled, and no other plugin after this one will have this hook function called, and the standard handler will also not be invoked. So, returning true effectively overrides the standard behavior of pause or resume.

Note that if you call pause() or resume() on the torrent from your handler it will recurse back into your handler, so in order to invoke the standard handler, you have to keep your own state on whether you want standard behavior or overridden behavior.

on_files_checked()

virtual void on_files_checked ();

This function is called when the initial files of the torrent have been checked. If there are no files to check, this function is called immediately.

i.e. This function is always called when the torrent is in a state where it can start downloading.

on_state()

virtual void on_state (torrent_status::state_t);

called when the torrent changes state the state is one of torrent_status::state_t enum members

on_add_peer()

virtual void on_add_peer (tcp::endpoint const&,
      peer_source_flags_t, add_peer_flags_t);

called every time a new peer is added to the peer list. This is before the peer is connected to. For flags, see torrent_plugin::flags_t. The source argument refers to the source where we learned about this peer from. It's a bitmask, because many sources may have told us about the same peer. For peer source flags, see peer_info::peer_source_flags.

first_time

this is the first time we see this peer

filtered

this peer was not added because it was filtered by the IP filter

type()

virtual string_view type () const;

This function is expected to return the name of the plugin.

add_handshake()

virtual void add_handshake (entry&);

can add entries to the extension handshake this is not called for web seeds

on_disconnect()

virtual void on_disconnect (error_code const&);

called when the peer is being disconnected.

on_connected()

virtual void on_connected ();

called when the peer is successfully connected. Note that incoming connections will have been connected by the time the peer plugin is attached to it, and won't have this hook called.

on_handshake()

virtual bool on_handshake (span<char const>);

this is called when the initial bittorrent handshake is received. Returning false means that the other end doesn't support this extension and will remove it from the list of plugins. this is not called for web seeds

on_extension_handshake()

virtual bool on_extension_handshake (bdecode_node const&);

called when the extension handshake from the other end is received if this returns false, it means that this extension isn't supported by this peer. It will result in this peer_plugin being removed from the peer_connection and destructed. this is not called for web seeds

on_bitfield() on_have_none() on_unchoke() on_have() on_choke() on_request() on_not_interested() on_interested() on_allowed_fast() on_have_all() on_dont_have()

virtual bool on_bitfield (bitfield const& /*bitfield*/);
virtual bool on_dont_have (piece_index_t);
virtual bool on_request (peer_request const&);
virtual bool on_unchoke ();
virtual bool on_interested ();
virtual bool on_have_all ();
virtual bool on_allowed_fast (piece_index_t);
virtual bool on_have_none ();
virtual bool on_choke ();
virtual bool on_not_interested ();
virtual bool on_have (piece_index_t);

returning true from any of the message handlers indicates that the plugin has handled the message. it will break the plugin chain traversing and not let anyone else handle the message, including the default handler.

on_piece()

virtual bool on_piece (peer_request const& /*piece*/
      , span<char const> /*buf*/);

This function is called when the peer connection is receiving a piece. buf points (non-owning pointer) to the data in an internal immutable disk buffer. The length of the data is specified in the length member of the piece parameter. returns true to indicate that the piece is handled and the rest of the logic should be ignored.

sent_unchoke()

virtual void sent_unchoke ();

called after a choke message has been sent to the peer

sent_payload()

virtual void sent_payload (int /* bytes */);

called after piece data has been sent to the peer this can be used for stats book keeping

can_disconnect()

virtual bool can_disconnect (error_code const& /*ec*/);

called when libtorrent think this peer should be disconnected. if the plugin returns false, the peer will not be disconnected.

on_extended()

virtual bool on_extended (int /*length*/, int /*msg*/,
      span<char const> /*body*/);

called when an extended message is received. If returning true, the message is not processed by any other plugin and if false is returned the next plugin in the chain will receive it to be able to handle it. This is not called for web seeds. thus function may be called more than once per incoming message, but only the last of the calls will the body size equal the length. i.e. Every time another fragment of the message is received, this function will be called, until finally the whole message has been received. The purpose of this is to allow early disconnects for invalid messages and for reporting progress of receiving large messages.

on_unknown_message()

virtual bool on_unknown_message (int /*length*/, int /*msg*/,
      span<char const> /*body*/);

this is not called for web seeds

on_piece_failed() on_piece_pass()

virtual void on_piece_failed (piece_index_t);
virtual void on_piece_pass (piece_index_t);

called when a piece that this peer participated in either fails or passes the hash_check

tick()

virtual void tick ();

called approximately once every second

write_request()

virtual bool write_request (peer_request const&);

called each time a request message is to be sent. If true is returned, the original request message won't be sent and no other plugin will have this function called.

decrypt()

virtual std::tuple<int, int, int> decrypt (span<span<char>> /*receive_vec*/) = 0;

decrypt the provided buffers. returns is a tuple representing the values (consume, produce, packet_size)

consume is set to the number of bytes which should be trimmed from the head of the buffers, default is 0

produce is set to the number of bytes of payload which are now ready to be sent to the upper layer. default is the number of bytes passed in receive_vec

packet_size is set to the minimum number of bytes which must be read to advance the next step of decryption. default is 0

create_torrent()

explicit create_torrent (file_storage& fs, int piece_size = 0
      , int pad_file_limit = -1, create_flags_t flags = optimize_alignment
      , int alignment = -1);
explicit create_torrent (torrent_info const& ti);

The piece_size is the size of each piece in bytes. It must be a multiple of 16 kiB. If a piece size of 0 is specified, a piece_size will be calculated such that the torrent file is roughly 40 kB.

If a pad_file_limit is specified (other than -1), any file larger than the specified number of bytes will be preceded by a pad file to align it with the start of a piece. The pad_file_limit is ignored unless the optimize_alignment flag is passed. Typically it doesn't make sense to set this any lower than 4 kiB.

The overload that takes a torrent_info object will make a verbatim copy of its info dictionary (to preserve the info-hash). The copy of the info dictionary will be used by create_torrent::generate(). This means that none of the member functions of create_torrent that affects the content of the info dictionary (such as set_hash()), will have any affect.

The flags arguments specifies options for the torrent creation. It can be any combination of the flags defined by create_torrent::flags_t.

alignment is used when pad files are enabled. This is the size eligible files are aligned to. The default is -1, which means the piece size of the torrent.

generate()

entry generate () const;

This function will generate the .torrent file as a bencode tree. In order to generate the flat file, use the bencode() function.

It may be useful to add custom entries to the torrent file before bencoding it and saving it to disk.

If anything goes wrong during torrent generation, this function will return an empty entry structure. You can test for this condition by querying the type of the entry:

file_storage fs;
// add file ...
create_torrent t(fs);
// add trackers and piece hashes ...
e = t.generate();

if (e.type() == entry::undefined_t)
{
        // something went wrong
}