<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>
<li>supports files > 2 gigabytes (currently only on windows).</li>
<li>supports the <ttclass="literal"><spanclass="pre">no_peer_id=1</span></tt> extension that will ease the load off trackers.</li>
<p>The easiest way to build libtorrent is probably to use <aclass="reference"href="http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=80982">boost-build</a>. Make sure you install it
correctly by setting the environment variable <ttclass="literal"><spanclass="pre">BOOST_BUILD_PATH</span></tt> and modifying the
<ttclass="literal"><spanclass="pre">user_config.jam</span></tt> to reflect the toolsets you have installed.</p>
<p>You also need to install <aclass="reference"href="http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041&release_id=214915">boost 1.31.0</a>.</p>
<p>Before you invoke <ttclass="literal"><spanclass="pre">bjam</span></tt> you have to set the environment variable <ttclass="literal"><spanclass="pre">BOOST_ROOT</span></tt> to the
path where you installed boost. This will be used to build and link against the required
boost libraries as well as be used as include path for boost headers.</p>
<p>If you're building on a platform where dlls share the same heap, you can build libtorrent
as a dll too, by typing <ttclass="literal"><spanclass="pre">link=shared</span></tt> instead of <ttclass="literal"><spanclass="pre">link=static</span></tt>.</p>
<p>To build on MacOS X, you need the latest version of boost-build, from the <aclass="reference"href="http://sourceforge.net/cvs/?group_id=7586">boost cvs</a>.</p>
cygwin, if you're building with gcc (mingw) you'll have to run it from a cygwin terminal.
Also, make sure the paths are correct in the different environments. In cygwin, the paths
(<ttclass="literal"><spanclass="pre">BOOST_BUILD_PATH</span></tt> and <ttclass="literal"><spanclass="pre">BOOST_ROOT</span></tt>) should be in the typical unix-format (e.g.
<ttclass="literal"><spanclass="pre">/cygdrive/c/boost_1_31_0</span></tt>). In the windows environment, they should have the typical
windows format (<ttclass="literal"><spanclass="pre">c:/boost_1_31_0</span></tt>).</p>
version of boost, <aclass="reference"href="http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041&release_id=178835">boost 1.30.2</a>. And you'll definately have to use the latest service
structure in the torrent-file. <ttclass="literal"><spanclass="pre">add_torrent</span></tt> will throw <aclass="reference"href="#duplicate-torrent">duplicate_torrent</a> exception
<aclass="reference"href="#duplicate-torrent">duplicate_torrent</a> which derives from <ttclass="literal"><spanclass="pre">std::exception</span></tt>.</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>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>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://wiki.theory.org/index.php/BitTorrentSpecification">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
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
<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">pause()</span></tt>, and <ttclass="literal"><spanclass="pre">resume()</span></tt> 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. You can use <ttclass="literal"><spanclass="pre">is_paused()</span></tt> to determine if a torrent
is currently paused. Torrents may be paused automatically if there is a file error (eg. disk full)
or something similar. See <aclass="reference"href="#file-error-alert">file_error_alert</a>.</p>
<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.
<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">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">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
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>This alert is generated when a peer is banned because it has sent too many corrupt pieces
to us. It is generated at severity level <ttclass="literal"><spanclass="pre">info</span></tt>. The <ttclass="literal"><spanclass="pre">handle</span></tt> member is a <aclass="reference"href="#torrent-handle">torrent_handle</a>
to the torrent that this peer was a member of.</p>
<p>The <ttclass="literal"><spanclass="pre">peer_request</span></tt> contains the values the client sent in its <ttclass="literal"><spanclass="pre">request</span></tt> message. <ttclass="literal"><spanclass="pre">piece</span></tt> is
the index of the piece it want data from, <ttclass="literal"><spanclass="pre">start</span></tt> is the offset within the piece where the data
should be read, and <ttclass="literal"><spanclass="pre">length</span></tt> is the amount of data it wants.</p>
<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>
