wornvirtue
/
premiere-libtorrent
forked from premiere/premiere-libtorrent
1
0
Fork 0
Code Pull Requests Activity

doc updates and started adding documentation for new plugin interface

This commit is contained in:
Arvid Norberg 2006-11-27 00:04:20 +00:00
parent b63c155c0d
commit d62801280f
9 changed files with 405 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
docs/extension_protocol.html
View File

@ -98,17 +98,21 @@ This is the defined item in the dictionary:</p>
</thead>
<tbody valign="top">
<tr><td>m</td>
<td>Dictionary of supported extension messages which maps
names of extensions to identification numbers of each
extension. The only requirement on the identification
numbers is that no extensions share the same. Setting
<td><p class="first">Dictionary of supported extension messages which maps
names of extensions to an extended message ID for each
extension message. The only requirement on these IDs
is that no extension message share the same one. Setting
an extension number to zero means that the extension is
not supported/disabled. The client should ignore any
extension names it doesn't recognize.</td>
extension names it doesn't recognize.</p>
<p class="last">The extension message IDs are the IDs used to send the
extension messages to the peer sending this handshake.
i.e. The IDs are local to this particular peer.</p>
</td>
</tr>
</tbody>
</table>
<p>Here are two other items that an implementation may choose to support:</p>
<p>Here are some other items that an implementation may choose to support:</p>
<table border="1" class="docutils">
<colgroup>
<col width="11%" />
@ -167,7 +171,7 @@ imaginable.</p>
<tr><td><tt class="docutils literal"><span class="pre">LT_metadata</span></tt></td>
<td>1</td>
</tr>
<tr><td><tt class="docutils literal"><span class="pre">µT_PEX</span></tt></td>
<tr><td><tt class="docutils literal"><span class="pre">ut_pex</span></tt></td>
<td>2</td>
</tr>
</tbody>
@ -214,8 +218,12 @@ extensions.</p>
<div class="section" id="rationale">
<h2><a name="rationale">rationale</a></h2>
<p>The reason why the extension messages' IDs would be defined in the handshake
is to avoid having a global registry somewhere, where ID's are assigned
global identifiers. Now the extensions have unique names.</p>
is to avoid having a global registry of message IDs. Instead the names of the
extension messages requires unique names, which is much easier to do without
a global registry. The convention is to use a two letter prefix on the
extension message names, the prefix would identify the client first
implementing the extension message. e.g. <tt class="docutils literal"><span class="pre">LT_metadata</span></tt> is implemented by
libtorrent, and hence it has the <tt class="docutils literal"><span class="pre">LT</span></tt> prefix.</p>
<p>If the client supporting the extensions can decide which numbers the messages
it receives will have, it means they are constants within that client. i.e.
they can be used in <tt class="docutils literal"><span class="pre">switch</span></tt> statements. It's easy for the other end to

23
docs/extension_protocol.rst
View File

@ -59,16 +59,20 @@ This is the defined item in the dictionary:
| name | description |
+=======+===========================================================+
| m | Dictionary of supported extension messages which maps |
| | names of extensions to identification numbers of each |
| | extension. The only requirement on the identification |
| | numbers is that no extensions share the same. Setting |
| | names of extensions to an extended message ID for each |
| | extension message. The only requirement on these IDs |
| | is that no extension message share the same one. Setting |
| | an extension number to zero means that the extension is |
| | not supported/disabled. The client should ignore any |
| | extension names it doesn't recognize. |
| | |
| | The extension message IDs are the IDs used to send the |
| | extension messages to the peer sending this handshake. |
| | i.e. The IDs are local to this particular peer. |
+-------+-----------------------------------------------------------+
Here are two other items that an implementation may choose to support:
Here are some other items that an implementation may choose to support:
+-------+-----------------------------------------------------------+
| name | description |
@ -102,7 +106,7 @@ An example of what the payload of a handshake message could look like:
| | +======================+===+ |
| | | ``LT_metadata`` | 1 | |
| | +----------------------+---+ |
| | | ``µT_PEX`` | 2 | |
| | | ``ut_pex`` | 2 | |
| | +----------------------+---+ |
| | |
+-------------------+----------------------------------+
@ -150,8 +154,12 @@ rationale
---------
The reason why the extension messages' IDs would be defined in the handshake
is to avoid having a global registry somewhere, where ID's are assigned
global identifiers. Now the extensions have unique names.
is to avoid having a global registry of message IDs. Instead the names of the
extension messages requires unique names, which is much easier to do without
a global registry. The convention is to use a two letter prefix on the
extension message names, the prefix would identify the client first
implementing the extension message. e.g. ``LT_metadata`` is implemented by
libtorrent, and hence it has the ``LT`` prefix.
If the client supporting the extensions can decide which numbers the messages
it receives will have, it means they are constants within that client. i.e.
@ -177,3 +185,4 @@ identifiers is 1) The mainline DHT uses single byte identifiers. 2) Saves
bandwidth. The only advantage of longer messages is that it makes the
protocol more readable for a human, but the BT protocol wasn't designed to
be a human readable protocol, so why bother.

1
docs/index.html
View File

@ -25,6 +25,7 @@
<p>Extensions</p>
<ul class="simple">
<li><a class="reference" href="extension_protocol.html">extensions protocol</a></li>
<li><a class="reference" href="libtorrent_plugins.html">plugin interface</a></li>
<li><a class="reference" href="dht_extensions.html">DHT extensions</a></li>
<li><a class="reference" href="udp_tracker_protocol.html">UDP tracker protocol</a></li>
<li><a class="reference" href="http://www.getright.com/seedtorrent.html">HTTP seed</a></li>

2
docs/index.rst
View File

@ -18,6 +18,7 @@
Extensions
* `extensions protocol`_
* `plugin interface`_
* `DHT extensions`_
* `UDP tracker protocol`_
* `HTTP seed`_
@ -50,6 +51,7 @@ libtorrent
.. _`api documentation`: manual.html
.. _screenshot: client_test.png
.. _`extensions protocol`: extension_protocol.html
.. _`plugin interface`: libtorrent_plugins.html
.. _`DHT extensions`: dht_extensions.html
.. _`UDP tracker protocol`: udp_tracker_protocol.html
.. _`HTTP seed`: http://www.getright.com/seedtorrent.html

188
docs/libtorrent_plugins.html Normal file
View File

@ -0,0 +1,188 @@
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.3.9: http://docutils.sourceforge.net/" />
<title></title>
<meta name="author" content="Arvid Norberg, arvid&#64;rasterbar.com" />
<link rel="stylesheet" href="style.css" type="text/css" />
</head>
<body>
<div class="document">
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr><th class="docinfo-name">Author:</th>
<td>Arvid Norberg, <a class="last reference" href="mailto:arvid&#64;rasterbar.com">arvid&#64;rasterbar.com</a></td></tr>
</tbody>
</table>
<div class="section" id="libtorrent-plugins">
<h1><a name="libtorrent-plugins">libtorrent plugins</a></h1>
<div class="contents topic" id="table-of-contents">
<p class="topic-title first"><a name="contents">Contents</a></p>
<ul class="simple">
<li><a class="reference" href="#libtorrent-plugins" id="id1" name="id1">libtorrent plugins</a><ul>
<li><a class="reference" href="#a-word-of-caution" id="id2" name="id2">a word of caution</a></li>
</ul>
</li>
<li><a class="reference" href="#plugin-interface" id="id3" name="id3">plugin interface</a></li>
<li><a class="reference" href="#torrent-plugin" id="id4" name="id4">torrent_plugin</a><ul>
<li><a class="reference" href="#new-connection" id="id5" name="id5">new_connection()</a></li>
<li><a class="reference" href="#on-piece-pass-on-piece-fail" id="id6" name="id6">on_piece_pass() on_piece_fail()</a></li>
<li><a class="reference" href="#tick" id="id7" name="id7">tick()</a></li>
<li><a class="reference" href="#on-pause-on-resume" id="id8" name="id8">on_pause() on_resume()</a></li>
</ul>
</li>
<li><a class="reference" href="#peer-plugin" id="id9" name="id9">peer_plugin</a></li>
</ul>
</div>
<p>libtorrent has a plugin interface for implementing extensions to the protocol.
These can be general extensions for transferring metadata or peer exchange
extensions, or it could be used to provide a way to customize the protocol
to fit a particular (closed) network.</p>
<p>In short, the plugin interface makes it possible to:</p>
<ul class="simple">
<li>register extension messages (sent in the extension handshake), see
<a class="reference" href="extension_protocol.html">extensions</a>.</li>
<li>add data and parse data from the extension handshake.</li>
<li>send extension messages and standard bittorrent messages.</li>
<li>override or block the handling of standard bittorrent messages.</li>
</ul>
<div class="section" id="a-word-of-caution">
<h2><a name="a-word-of-caution">a word of caution</a></h2>
<p>Writing your own plugin is a very easy way to introduce serious bugs such as
dead locks and race conditions. Since a plugin has access to internal
structures it is also quite easy to sabotage libtorrent's operation.</p>
<p>All the callbacks in this interface are called with the main libtorrent thread
mutex locked. And they are always called from the libtorrent main thread. In
case portions of your plugin are called from other threads, typically the main
thread, you cannot use any of the member functions on the internal structures
in libtorrent, since those require the mutex to be locked. Futhermore, you would
also need to have a mutex on your own shared data within the plugin, to make
sure it is not accessed at the same time from the libtorrent thread (through a
callback). See <a class="reference" href="http://www.boost.org/doc/html/mutex.html">boost thread's mutex</a>. If you need to send out a message from
another thread, use an internal queue, and do the actual sending in <tt class="docutils literal"><span class="pre">tick()</span></tt>.</p>
</div>
</div>
<div class="section" id="plugin-interface">
<h1><a name="plugin-interface">plugin interface</a></h1>
<p>The plugin interface consists of two base classes that the plugin may
implement. These are called <tt class="docutils literal"><span class="pre">torrent_plugin</span></tt> and <tt class="docutils literal"><span class="pre">peer_plugin</span></tt>. They are
both found in the <tt class="docutils literal"><span class="pre">&lt;libtorrent/extensions.hpp&gt;</span></tt> header.</p>
<p>These plugins are instantiated for each torrent and possibly each peer,
respectively.</p>
</div>
<div class="section" id="torrent-plugin">
<h1><a name="torrent-plugin">torrent_plugin</a></h1>
<p>The synopsis for <tt class="docutils literal"><span class="pre">torrent_plugin</span></tt> follows:</p>
<pre class="literal-block">
struct torrent_plugin
{
virtual ~torrent_plugin();
virtual boost::shared_ptr&lt;peer_plugin&gt; new_connection(peer_connection*);
virtual void on_piece_pass(int index);
virtual void on_piece_failed(int index);
virtual void tick();
virtual bool on_pause();
virtual bool on_resume();
};
</pre>
<p>This is the base class for a torrent_plugin. Your derived class is (if added
as an extension) instantiated for each torrent in the session. The callback
hook functions are defined as follows.</p>
<div class="section" id="new-connection">
<h2><a name="new-connection">new_connection()</a></h2>
<pre class="literal-block">
boost::shared_ptr&lt;peer_plugin&gt; new_connection(peer_connection*);
</pre>
<p>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
<tt class="docutils literal"><span class="pre">shared_ptr</span></tt> (in which case you don't need to override this member
function).</p>
<p>If you need an extension to the peer connection (which most plugins do) you
are supposed to return an instance of your <tt class="docutils literal"><span class="pre">peer_plugin</span></tt> class. Which in
turn will have its hook functions called on event specific to that peer.</p>
<p>The <tt class="docutils literal"><span class="pre">peer_connection</span></tt> will be valid as long as the <tt class="docutils literal"><span class="pre">shared_ptr</span></tt> is being
held by the torrent object. So, it is generally a good idea to not keep a
<tt class="docutils literal"><span class="pre">shared_ptr</span></tt> to your own peer_plugin. If you want to keep references to it,
use <tt class="docutils literal"><span class="pre">weak_ptr</span></tt>.</p>
<p>If this function throws an exception, the connection will be closed.</p>
</div>
<div class="section" id="on-piece-pass-on-piece-fail">
<h2><a name="on-piece-pass-on-piece-fail">on_piece_pass() on_piece_fail()</a></h2>
<pre class="literal-block">
void on_piece_pass(int index);
void on_piece_failed(int index);
</pre>
<p>These hooks are called when a piece passes the hash check or fails the hash
check, respectively. The <tt class="docutils literal"><span class="pre">index</span></tt> is the piece index that was downloaded.
It is possible to access the list of peers that participated in sending the
piece through the <tt class="docutils literal"><span class="pre">torrent</span></tt> and the <tt class="docutils literal"><span class="pre">piece_picker</span></tt>.</p>
</div>
<div class="section" id="tick">
<h2><a name="tick">tick()</a></h2>
<pre class="literal-block">
void tick();
</pre>
<p>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.</p>
</div>
<div class="section" id="on-pause-on-resume">
<h2><a name="on-pause-on-resume">on_pause() on_resume()</a></h2>
<pre class="literal-block">
bool on_pause();
bool on_resume();
</pre>
<p>These hooks are called when the torrent is paused and unpaused respectively.
The return value indicates if the event was handled. A return value of
<tt class="docutils literal"><span class="pre">true</span></tt> 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 unpause.</p>
<p>Note that if you call <tt class="docutils literal"><span class="pre">pause()</span></tt> or <tt class="docutils literal"><span class="pre">resume()</span></tt> 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.</p>
</div>
</div>
<div class="section" id="peer-plugin">
<h1><a name="peer-plugin">peer_plugin</a></h1>
<pre class="literal-block">
struct peer_plugin
{
virtual ~peer_plugin();
virtual void add_handshake(entry&amp;);
virtual bool on_handshake();
virtual bool on_extension_handshake(entry const&amp; h);
virtual bool on_choke();
virtual bool on_unchoke();
virtual bool on_interested();
virtual bool on_not_interested();
virtual bool on_have(int index);
virtual bool on_bitfield(std::vector&lt;bool&gt; const&amp; bitfield);
virtual bool on_request(peer_request const&amp; req);
virtual bool on_piece(peer_request const&amp; piece, char const* data);
virtual bool on_cancel(peer_request const&amp; req);
virtual bool on_extended(int length
, int msg, buffer::const_interval body);
virtual bool on_unknown_message(int length, int msg
, buffer::const_interval body);
virtual void on_piece_pass(int index);
virtual void on_piece_failed(int index);
virtual void tick();
virtual bool write_request(peer_request const&amp; r);
};
</pre>
</div>
</div>
</body>
</html>

179
docs/libtorrent_plugins.rst Normal file
View File

@ -0,0 +1,179 @@
:Author: Arvid Norberg, arvid@rasterbar.com
libtorrent plugins
==================
.. contents::
libtorrent has a plugin interface for implementing extensions to the protocol.
These can be general extensions for transferring metadata or peer exchange
extensions, or it could be used to provide a way to customize the protocol
to fit a particular (closed) network.
In short, the plugin interface makes it possible to:
* register extension messages (sent in the extension handshake), see
extensions_.
* add data and parse data from the extension handshake.
* send extension messages and standard bittorrent messages.
* override or block the handling of standard bittorrent messages.
.. _extensions: extension_protocol.html
a word of caution
-----------------
Writing your own plugin is a very easy way to introduce serious bugs such as
dead locks and race conditions. Since a plugin has access to internal
structures it is also quite easy to sabotage libtorrent's operation.
All the callbacks in this interface are called with the main libtorrent thread
mutex locked. And they are always called from the libtorrent main thread. In
case portions of your plugin are called from other threads, typically the main
thread, you cannot use any of the member functions on the internal structures
in libtorrent, since those require the mutex to be locked. Futhermore, you would
also need to have a mutex on your own shared data within the plugin, to make
sure it is not accessed at the same time from the libtorrent thread (through a
callback). See `boost thread's mutex`_. If you need to send out a message from
another thread, use an internal queue, and do the actual sending in ``tick()``.
.. _`boost thread's mutex`: http://www.boost.org/doc/html/mutex.html
plugin interface
================
The plugin interface consists of two base classes that the plugin may
implement. These are called ``torrent_plugin`` and ``peer_plugin``. They are
both found in the ``<libtorrent/extensions.hpp>`` header.
These plugins are instantiated for each torrent and possibly each peer,
respectively.
torrent_plugin
==============
The synopsis for ``torrent_plugin`` follows::
struct torrent_plugin
{
virtual ~torrent_plugin();
virtual boost::shared_ptr<peer_plugin> new_connection(peer_connection*);
virtual void on_piece_pass(int index);
virtual void on_piece_failed(int index);
virtual void tick();
virtual bool on_pause();
virtual bool on_resume();
};
This is the base class for a torrent_plugin. Your derived class is (if added
as an extension) instantiated for each torrent in the session. The callback
hook functions are defined as follows.
new_connection()
----------------
::
boost::shared_ptr<peer_plugin> new_connection(peer_connection*);
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`` 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_pass() on_piece_fail()
-------------------------------
::
void on_piece_pass(int index);
void on_piece_failed(int index);
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()
------
::
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_pause() on_resume()
----------------------
::
bool on_pause();
bool on_resume();
These hooks are called when the torrent is paused and unpaused 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 unpause.
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.
peer_plugin
===========
::
struct peer_plugin
{
virtual ~peer_plugin();
virtual void add_handshake(entry&);
virtual bool on_handshake();
virtual bool on_extension_handshake(entry const& h);
virtual bool on_choke();
virtual bool on_unchoke();
virtual bool on_interested();
virtual bool on_not_interested();
virtual bool on_have(int index);
virtual bool on_bitfield(std::vector<bool> const& bitfield);
virtual bool on_request(peer_request const& req);
virtual bool on_piece(peer_request const& piece, char const* data);
virtual bool on_cancel(peer_request const& req);
virtual bool on_extended(int length
, int msg, buffer::const_interval body);
virtual bool on_unknown_message(int length, int msg
, buffer::const_interval body);
virtual void on_piece_pass(int index);
virtual void on_piece_failed(int index);
virtual void tick();
virtual bool write_request(peer_request const& r);
};

2
docs/manual.html
View File

@ -18,7 +18,7 @@
<tr><th class="docinfo-name">Author:</th>
<td>Arvid Norberg, <a class="last reference" href="mailto:arvid&#64;rasterbar.com">arvid&#64;rasterbar.com</a></td></tr>
<tr><th class="docinfo-name">Version:</th>
<td>0.11</td></tr>
<td>0.12</td></tr>
</tbody>
</table>
<div class="contents topic" id="table-of-contents">

2
docs/manual.rst
View File

@ -3,7 +3,7 @@ libtorrent API Documentation
============================
:Author: Arvid Norberg, arvid@rasterbar.com
:Version: 0.11
:Version: 0.12
.. contents:: Table of contents
:depth: 2

1
docs/style.css
View File

@ -244,7 +244,6 @@ div.contents {
padding: 0 0 0 0.8em;
list-style: none;
text-align: left;
/* line-height: 1.5em;*/
}
#table-of-contents a.reference {