<li>Supports the extension protocol <aclass="reference"href="http://nolar.com/azureus/extended.htm">described by Nolar</a>. See <aclass="reference"href="#extensions">extensions</a>.</li>
<p>Once it's created, it will spawn the main thread that will do all the work.
The main thread will be idle as long it doesn't have any torrents to participate in.
You add torrents through the <ttclass="literal"><spanclass="pre">add_torrent()</span></tt>-function where you give an
object representing the information found in the torrent file and the path where you
want to save the files. The <ttclass="literal"><spanclass="pre">save_path</span></tt> will be prepended to the directory-
structure in the torrent-file. <ttclass="literal"><spanclass="pre">add_torrent</span></tt> will throw <ttclass="literal"><spanclass="pre">duplicate_torrent</span></tt> exception
if the torrent already exists in the session.</p>
<p>The optional last parameter, <ttclass="literal"><spanclass="pre">resume_data</span></tt> can be given if up to date fast-resume data
is available. The fast-resume data can be acquired from a running torrent by calling
<ttclass="literal"><spanclass="pre">torrent_handle::write_resume_data()</span></tt>. See <aclass="reference"href="#fast-resume">fast resume</a>.</p>
<p><ttclass="literal"><spanclass="pre">remove_torrent()</span></tt> will close all peer connections associated with the torrent and tell
the tracker that we've stopped participating in the swarm.</p>
<p>If the torrent you are trying to add already exists in the session (is either queued
for checking, being checked or downloading) <ttclass="literal"><spanclass="pre">add_torrent()</span></tt> will throw
<ttclass="literal"><spanclass="pre">duplicate_torrent</span></tt> which derives from <ttclass="literal"><spanclass="pre">std::exception</span></tt>.</p>
<p>The difference between the two constructors is that one of them takes a fingerprint
as argument. If this is ommited, the client will get a default fingerprint stating
the version of libtorrent. The fingerprint is a short string that will be used in
the peer-id to identify the client and the client's version. For more details see the
fingerprint class.</p>
<p><ttclass="literal"><spanclass="pre">set_upload_rate_limit()</span></tt> set the maximum number of bytes allowed to be
sent to peers per second. This bandwidth is distributed among all the peers. If
you don't want to limit upload rate, you can set this to -1 (the default).</p>
<p>The destructor of session will notify all trackers that our torrents has been shut down.
If some trackers are down, they will timout. All this before the destructor of session
returns. So, it's adviced that any kind of interface (such as windows) are closed before
destructing the sessoin object. Because it can take a few second for it to finish. The
timeout can be set with <ttclass="literal"><spanclass="pre">set_http_settings()</span></tt>.</p>
<p>How to parse a torrent file and create a <ttclass="literal"><spanclass="pre">torrent_info</span></tt> object is described below.</p>
<p>The <aclass="reference"href="#torrent-handle">torrent_handle</a> returned by <ttclass="literal"><spanclass="pre">add_torrent</span></tt> can be used to retrieve information
about the torrent's progress, its peers etc. It is also used to abort a torrent.</p>
<p>The constructor takes a listen port as argument, if the given port is busy it will
increase the port number by one and try again. If it still fails it will continue
increasing the port number until it succeeds or has failed 9 ports. <em>This will
change in the future to give more control of the listen-port.</em></p>
<p>For information about the <ttclass="literal"><spanclass="pre">pop_alert()</span></tt> function, see <aclass="reference"href="#alerts">alerts</a>.</p>
<p>The torrent files are <aclass="reference"href="http://bitconjurer.org/BitTorrent/protocol.html">bencoded</a>. There are two functions in libtorrent that can encode and decode
<p>The <aclass="reference"href="#entry">entry</a> class is the internal representation of the bencoded data
and it can be used to retreive information, an <aclass="reference"href="#entry">entry</a> can also be build by
the program and given to <ttclass="literal"><spanclass="pre">bencode()</span></tt> to encode it into the <ttclass="literal"><spanclass="pre">OutIt</span></tt>
iterator.</p>
<p>The <ttclass="literal"><spanclass="pre">OutIt</span></tt> and <ttclass="literal"><spanclass="pre">InIt</span></tt> are iterators
(<ttclass="literal"><spanclass="pre">InputIterator_</span></tt> and <ttclass="literal"><spanclass="pre">OutputIterator_</span></tt> respectively). They
are templates and are usually instantiated as <ttclass="literal"><spanclass="pre">ostream_iterator_</span></tt>,
<ttclass="literal"><spanclass="pre">back_insert_iterator_</span></tt> or <ttclass="literal"><spanclass="pre">istream_iterator_</span></tt>. These
functions will assume that the iterator refers to a character
(<ttclass="literal"><spanclass="pre">char</span></tt>). So, if you want to encode entry <ttclass="literal"><spanclass="pre">e</span></tt> into a buffer
void print(std::ostream& os, int indent = 0) const;
};
</pre>
<p>The <ttclass="literal"><spanclass="pre">integer()</span></tt>, <ttclass="literal"><spanclass="pre">string()</span></tt>, <ttclass="literal"><spanclass="pre">list()</span></tt> and <ttclass="literal"><spanclass="pre">dict()</span></tt> functions
are accessorts that return the respecive type. If the <ttclass="literal"><spanclass="pre">entry</span></tt> object isn't of the
type you request, the accessor will throw <aclass="reference"href="#type-error">type_error</a> (which derives from
<ttclass="literal"><spanclass="pre">std::runtime_error</span></tt>). You can ask an <ttclass="literal"><spanclass="pre">entry</span></tt> for its type through the
entry::integer_type piece_size(unsigned int index) const;
const sha1_hash& hash_for_piece(unsigned int index) const;
};
</pre>
<p>This class will need some explanation. First of all, to get a list of all files
in the torrent, you can use <ttclass="literal"><spanclass="pre">begin_files()</span></tt>, <ttclass="literal"><spanclass="pre">end_files()</span></tt>,
<ttclass="literal"><spanclass="pre">rbegin_files()</span></tt> and <ttclass="literal"><spanclass="pre">rend_files()</span></tt>. These will give you standard vector
iterators with the type <ttclass="literal"><spanclass="pre">file</span></tt>.</p>
<preclass="literal-block">
struct file
{
std::string path;
std::string filename;
entry::integer_type size;
};
</pre>
<p>If you need index-access to files you can use the <ttclass="literal"><spanclass="pre">num_files()</span></tt> and <ttclass="literal"><spanclass="pre">file_at()</span></tt>
to access files using indices.</p>
<p>The <ttclass="literal"><spanclass="pre">print()</span></tt> function is there for debug purposes only. It will print the info from
the torrent file to the given outstream.</p>
<p><ttclass="literal"><spanclass="pre">name()</span></tt> returns the name of the torrent.</p>
<p>The <ttclass="literal"><spanclass="pre">trackers()</span></tt> function will return a sorted vector of <ttclass="literal"><spanclass="pre">announce_entry</span></tt>.
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.</p>
<preclass="literal-block">
struct announce_entry
{
std::string url;
int tier;
};
</pre>
<p>The <ttclass="literal"><spanclass="pre">prioritize_tracker()</span></tt> is used internally to move a tracker to the front
of its tier group. i.e. It will never be moved pass a tracker with a different tier
number. For more information about how multiple trackers are dealt with, see the
<p><ttclass="literal"><spanclass="pre">total_size()</span></tt>, <ttclass="literal"><spanclass="pre">piece_length()</span></tt> and <ttclass="literal"><spanclass="pre">num_pieces()</span></tt> 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
<ttclass="literal"><spanclass="pre">piece_size()</span></tt> and <ttclass="literal"><spanclass="pre">piece_length()</span></tt> is that <ttclass="literal"><spanclass="pre">piece_size()</span></tt> takes
the piece index as argument and gives you the exact size of that piece. It will always
be the same as <ttclass="literal"><spanclass="pre">piece_length()</span></tt> except in the case of the last piece, which may
be smaller.</p>
<p><ttclass="literal"><spanclass="pre">hash_for_piece()</span></tt> takes a piece-index and returns the 20-bytes sha1-hash for that
piece and <ttclass="literal"><spanclass="pre">info_hash()</span></tt> returns the 20-bytes sha1-hash for the info-section of the
torrent file. For more information on the <ttclass="literal"><spanclass="pre">sha1_hash</span></tt>, see the <aclass="reference"href="#big-number">big_number</a> class.</p>
<p><ttclass="literal"><spanclass="pre">comment()</span></tt> returns the comment associated with the torrent. If there's no comment,
it will return an empty string. <ttclass="literal"><spanclass="pre">creation_date()</span></tt> returns a <aclass="reference"href="http://www.boost.org/libs/date_time/doc/class_ptime.html">boost::posix_time::ptime</a>
object, representing the time when this torrent file was created. If there's no timestamp
in the torrent file, this will return a date of january 1:st 1970.</p>
<p>The default constructor will initialize the handle to an invalid state. Which means you cannot
perform any operation on it, unless you first assign it a valid handle. If you try to perform
any operation on an uninitialized handle, it will throw <ttclass="literal"><spanclass="pre">invalid_handle</span></tt>.</p>
<p><ttclass="literal"><spanclass="pre">save_path()</span></tt> returns the path that was given to <ttclass="literal"><spanclass="pre">add_torrent()</span></tt> when this torrent
<p><ttclass="literal"><spanclass="pre">status()</span></tt> will return a structure with information about the status of this
torrent. If the <aclass="reference"href="#torrent-handle">torrent_handle</a> is invalid, it will throw <aclass="reference"href="#invalid-handle">invalid_handle</a> exception.
It contains the following fields:</p>
<preclass="literal-block">
struct torrent_status
{
enum state_t
{
invalid_handle,
queued_for_checking,
checking_files,
connecting_to_tracker,
downloading,
seeding
};
state_t state;
float progress;
boost::posix_time::time_duration next_announce;
std::size_t total_download;
std::size_t total_upload;
std::size_t total_payload_download;
std::size_t total_payload_upload;
float download_rate;
float upload_rate;
std::vector<bool> pieces;
std::size_t total_done;
};
</pre>
<p><ttclass="literal"><spanclass="pre">progress</span></tt> is a value in the range [0, 1], that represents the progress of the
torrent's current task. It may be checking files or downloading. The torrent's
current task is in the <ttclass="literal"><spanclass="pre">state</span></tt> member, it will be one of the following:</p>
<td>In this state the torrent has finished downloading and
is a pure seeder.</td>
</tr>
</tbody>
</table>
<p><ttclass="literal"><spanclass="pre">next_announce</span></tt> is the time until the torrent will announce itself to the tracker.</p>
<p><ttclass="literal"><spanclass="pre">total_download</span></tt> and <ttclass="literal"><spanclass="pre">total_upload</span></tt> is the number of bytes downloaded and
uploaded to all peers, accumulated, <em>this session</em> only.</p>
<p><ttclass="literal"><spanclass="pre">total_payload_download</span></tt> and <ttclass="literal"><spanclass="pre">total_payload_upload</span></tt> counts the amount of bytes
send and received this session, but only the actual oayload data (i.e the interesting
data), these counters ignore any protocol overhead.</p>
<p><ttclass="literal"><spanclass="pre">pieces</span></tt> is the bitmask that representw which pieces we have (set to true) and
the pieces we don't have.</p>
<p><ttclass="literal"><spanclass="pre">download_rate</span></tt> and <ttclass="literal"><spanclass="pre">upload_rate</span></tt> are 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.</p>
<p><ttclass="literal"><spanclass="pre">total_done</span></tt> is the total number of bytes of the file(s) that we have.</p>
<p><ttclass="literal"><spanclass="pre">piece_index</span></tt> is the index of the piece in question. <ttclass="literal"><spanclass="pre">blocks_in_piece</span></tt> is the
number of blocks in this particular piece. This number will be the same for most pieces, but
the last piece may have fewer blocks than the standard pieces.</p>
<p><ttclass="literal"><spanclass="pre">requested_blocks</span></tt> is a bitset with one bit per block in the piece. If a bit is set, it
means that that block has been requested, but not necessarily fully downloaded yet. To know
from whom the block has been requested, have a look in the <ttclass="literal"><spanclass="pre">peer</span></tt> array. The bit-index
in the <ttclass="literal"><spanclass="pre">requested_blocks</span></tt> and <ttclass="literal"><spanclass="pre">finished_blocks</span></tt> correspons to the array-index into
<ttclass="literal"><spanclass="pre">peers</span></tt> and <ttclass="literal"><spanclass="pre">num_downloads</span></tt>. The array of peers is contains the id of the
peer the piece was requested from. If a piece hasn't been requested (the bit in
<ttclass="literal"><spanclass="pre">requested_blocks</span></tt> is not set) the peer array entry will be undefined.</p>
<p>The <ttclass="literal"><spanclass="pre">finished_blocks</span></tt> is a bitset where each bit says if the block is fully downloaded
or not. And the <ttclass="literal"><spanclass="pre">num_downloads</span></tt> array says how many times that block has been downloaded.
When a piece fails a hash verification, single blocks may be redownloaded to see if the hash teast
<p><ttclass="literal"><spanclass="pre">get_peer_info()</span></tt> 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
<aclass="reference"href="#torrent-handle">torrent_handle</a> is invalid, it will throw <aclass="reference"href="#invalid-handle">invalid_handle</a> exception. Each entry in
the vector contains information about that particular peer. It contains the following
<p>The <ttclass="literal"><spanclass="pre">ip</span></tt> field is the IP-address to this peer. Its type is a wrapper around the
actual address and the port number. See <aclass="reference"href="#address">address</a> class.</p>
<p><ttclass="literal"><spanclass="pre">up_speed</span></tt> and <ttclass="literal"><spanclass="pre">down_speed</span></tt> is the current upload and download speed
we have to and from this peer. These figures are updated aproximately once every second.</p>
<p><ttclass="literal"><spanclass="pre">total_download</span></tt> and <ttclass="literal"><spanclass="pre">total_upload</span></tt> are 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.</p>
<p><ttclass="literal"><spanclass="pre">id</span></tt> is 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
<p>Returns a const reference to the <ttclass="literal"><spanclass="pre">torrent_info</span></tt> object associated with this torrent.
This reference is valid as long as the <aclass="reference"href="#torrent-handle">torrent_handle</a> is valid, no longer. If the
<aclass="reference"href="#torrent-handle">torrent_handle</a> is invalid, <aclass="reference"href="#invalid-handle">invalid_handle</a> exception will be thrown.</p>
<p>The <ttclass="literal"><spanclass="pre">address</span></tt> class represents a name of a network endpoint (usually referred to as
IP-address) and a port number. This is the same thing as a <ttclass="literal"><spanclass="pre">sockaddr_in</span></tt> would contain.
Its declaration looks like this:</p>
<preclass="literal-block">
class address
{
public:
address();
address(unsigned char a
, unsigned char b
, unsigned char c
, unsigned char d
, unsigned short port);
address(unsigned int addr, unsigned short port);
address(const std::string& addr, unsigned short port);
address(const address& a);
~address();
std::string as_string() const;
unsigned int ip() const;
unsigned short port() const;
bool operator<(const address& a) const;
bool operator!=(const address& a) const;
bool operator==(const address& a) const;
};
</pre>
<p>It is less-than comparable to make it possible to use it as a key in a map. <ttclass="literal"><spanclass="pre">as_string()</span></tt> may block
while it does the DNS lookup, it returns a string that points to the address represented by the object.</p>
<p><ttclass="literal"><spanclass="pre">ip()</span></tt> will return the 32-bit ip-address as an integer. <ttclass="literal"><spanclass="pre">port()</span></tt> returns the port number.</p>
<p>You have some control over tracker requests through the <ttclass="literal"><spanclass="pre">http_settings</span></tt> object. You
create it and fill it with your settings and the use <ttclass="literal"><spanclass="pre">session::set_http_settings()</span></tt>
to apply them. You have control over proxy and authorization settings and also the user-agent
that will be sent to the tracker. The user-agent is a good way to identify your client.</p>
<preclass="literal-block">
struct http_settings
{
http_settings();
std::string proxy_ip;
int proxy_port;
std::string proxy_login;
std::string proxy_password;
std::string user_agent;
int tracker_timeout;
int tracker_maximum_response_length;
};
</pre>
<p><ttclass="literal"><spanclass="pre">proxy_ip</span></tt> may be a hostname or ip to a http proxy to use. If this is
an empty string, no http proxy will be used.</p>
<p><ttclass="literal"><spanclass="pre">proxy_port</span></tt> is the port on which the http proxy listens. If <ttclass="literal"><spanclass="pre">proxy_ip</span></tt>
is empty, this will be ignored.</p>
<p><ttclass="literal"><spanclass="pre">proxy_login</span></tt> should be the login username for the http proxy, if this
empty, the http proxy will be trid to be used without authentication.</p>
<p><ttclass="literal"><spanclass="pre">proxy_password</span></tt> the password string for the http proxy.</p>
<p><ttclass="literal"><spanclass="pre">user_agent</span></tt> this is the client identification to the tracker. It will
be followed by the string "(libtorrent)" to identify that this library
is being used. This should be set to your client's name and version number.</p>
<p><ttclass="literal"><spanclass="pre">tracker_timeout</span></tt> is the number of seconds the tracker connection will
wait until it considers the tracker to have timed-out. Default value is 10
seconds.</p>
<p><ttclass="literal"><spanclass="pre">tracker_maximum_response_length</span></tt> is the maximum number of bytes in a
tracker response. If a response size passes this number it will be rejected
and the connection will be closed. On gzipped responses this size is measured
on the uncompressed data. So, if you get 20 bytes of gzip response that'll
expand to 2 megs, it will be interrupted before the entire response has been
uncompressed (given your limit is lower than 2 megs). Default limit is
<p>Both the <ttclass="literal"><spanclass="pre">peer_id</span></tt> and <ttclass="literal"><spanclass="pre">sha1_hash</span></tt> types are typedefs of the class
<ttclass="literal"><spanclass="pre">big_number</span></tt>. It represents 20 bytes of data. Its synopsis follows:</p>
<preclass="literal-block">
class big_number
{
public:
bool operator==(const big_number& n) const;
bool operator!=(const big_number& n) const;
bool operator<(const big_number& n) const;
const unsigned char* begin() const;
const unsigned char* end() const;
unsigned char* begin();
unsigned char* end();
};
</pre>
<p>The iterators gives you access to individual bytes.</p>
<p>The fingerprint class represents information about a client and its version. It is used
to encode this information into the client's peer id.</p>
<p>This is the class declaration:</p>
<preclass="literal-block">
struct fingerprint
{
fingerprint(const char* id_string, int major, int minor, int revision, int tag);
std::string to_string() const;
char id[2];
char major_version;
char minor_version;
char revision_version;
char tag_version;
};
</pre>
<p>The constructor takes a <ttclass="literal"><spanclass="pre">const</span><spanclass="pre">char*</span></tt> that should point to a string constant containing
exactly two characters. These are the characters that should be unique for your client. Make
sure not to clash with anybody else. Here are some taken id's:</p>
<tableborderclass="table">
<colgroup>
<colwidth="30%"/>
<colwidth="70%"/>
</colgroup>
<theadvalign="bottom">
<tr><th>id chars</th>
<th>client</th>
</tr>
</thead>
<tbodyvalign="top">
<tr><td>'AZ'</td>
<td>Azureus</td>
</tr>
<tr><td>'LT'</td>
<td>libtorrent (default)</td>
</tr>
<tr><td>'BX'</td>
<td>BittorrentX</td>
</tr>
<tr><td>'MT'</td>
<td>Moonlight Torrent</td>
</tr>
</tbody>
</table>
<p>The <ttclass="literal"><spanclass="pre">major</span></tt>, <ttclass="literal"><spanclass="pre">minor</span></tt>, <ttclass="literal"><spanclass="pre">revision</span></tt> and <ttclass="literal"><spanclass="pre">tag</span></tt> parameters are used to identify the
version of your client. All these numbers must be within the range [0, 9].</p>
<p><ttclass="literal"><spanclass="pre">to_string()</span></tt> will generate the actual string put in the peer-id, and return it.</p>
<td>This will include alot of debug events that can be used
both for debugging libtorrent but also when debugging
other clients that are connected to libtorrent. It will
report strange behaviors among the connected peers.</td>
</tr>
</tbody>
</table>
<p>When setting a severity level, you will receive messages of that severity and all
messages that are more sever. If you set <ttclass="literal"><spanclass="pre">alert::none</span></tt> (the default) you will not recieve
any events at all.</p>
<p>When you set a severuty level other than <ttclass="literal"><spanclass="pre">none</span></tt>, you have the responsibility to call
<ttclass="literal"><spanclass="pre">pop_alert()</span></tt> from time to time. If you don't do that, the alert queue will just grow.</p>
<p>When you get an alert, you can use <ttclass="literal"><spanclass="pre">typeid()</span></tt> or <ttclass="literal"><spanclass="pre">dynamic_cast<></span></tt> to get more detailed
information on exactly which type it is. i.e. what kind of error it is. You can also use a
<aclass="reference"href="#dispatcher">dispatcher</a> mechanism that's available in libtorrent.</p>
<p>The <ttclass="literal"><spanclass="pre">alert</span></tt> class is the base class that specific messages are derived from. This
<p>This is thrown from the accessors of <ttclass="literal"><spanclass="pre">entry</span></tt> if the data type of the <ttclass="literal"><spanclass="pre">entry</span></tt> doesn't
<p>The fast resume mechanism is a way to remember which pieces are downloaded and where they
are put between sessions. You can generate fast resume data by calling
<ttclass="literal"><spanclass="pre">torrent_handle::write_resume_data()</span></tt> on <aclass="reference"href="#torrent-handle">torrent_handle</a>. You can then save this data
to disk and use it when resuming the torrent. libtorrent will not check the piece hashes
then, and rely on the information given in the fast-resume data. The fast-resume data
also contains information about which blocks, in the unfinished pieces, were downloaded,
so it will not have to start from scratch on the partially downloaded pieces.</p>
<p>To use the fast-resume data you simply give it to <ttclass="literal"><spanclass="pre">session::add_torrent()</span></tt>, and it
will skip the time consuming checks. It may have to do the checking anyway, if the
fast-resume data is corrupt or doesn't fit the storage for that torrent, then it will
not trust the fast-resume data and just do the checking.</p>
