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

merged changes from RC_1_0

This commit is contained in:
Arvid Norberg 2014-09-03 22:28:28 +00:00
parent 6bbdd4afa4
commit 4fcfaee438
4 changed files with 328 additions and 157 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

169
docs/extension_protocol.html
View File

@ -289,6 +289,175 @@ protocol more readable for a human, but the BT protocol wasn't designed to
be a human readable protocol, so why bother.</p>
</div>
</div>
<div class="section" id="extensions">
<h1>extensions</h1>
<p>These extensions all operates within the <a class="reference external" href="extension_protocol.html">extension protocol</a>. The name of the
extension is the name used in the extension-list packets, and the payload is
the data in the extended message (not counting the length-prefix, message-id
nor extension-id).</p>
<p>Note that since this protocol relies on one of the reserved bits in the
handshake, it may be incompatible with future versions of the mainline
bittorrent client.</p>
<p>These are the extensions that are currently implemented.</p>
<div class="section" id="metadata-from-peers">
<h2>metadata from peers</h2>
<p>Extension name: &quot;LT_metadata&quot;</p>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">This extension is deprecated in favor of the more widely supported
<tt class="docutils literal">ut_metadata</tt> extension, see <a class="reference external" href="http://bittorrent.org/beps/bep_0009.html">BEP 9</a>.</p>
</div>
<p>The point with this extension is that you don't have to distribute the
metadata (.torrent-file) separately. The metadata can be distributed
through the bittorrent swarm. The only thing you need to download such
a torrent is the tracker url and the info-hash of the torrent.</p>
<p>It works by assuming that the initial seeder has the metadata and that the
metadata will propagate through the network as more peers join.</p>
<p>There are three kinds of messages in the metadata extension. These packets are
put as payload to the extension message. The three packets are:</p>
<blockquote>
<ul class="simple">
<li>request metadata</li>
<li>metadata</li>
<li>don't have metadata</li>
</ul>
</blockquote>
<p>request metadata:</p>
<table border="1" class="docutils">
<colgroup>
<col width="17%" />
<col width="23%" />
<col width="61%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">size</th>
<th class="head">name</th>
<th class="head">description</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>uint8_t</td>
<td>msg_type</td>
<td>Determines the kind of message this is
0 means 'request metadata'</td>
</tr>
<tr><td>uint8_t</td>
<td>start</td>
<td>The start of the metadata block that
is requested. It is given in 256:ths
of the total size of the metadata,
since the requesting client don't know
the size of the metadata.</td>
</tr>
<tr><td>uint8_t</td>
<td>size</td>
<td>The size of the metadata block that is
requested. This is also given in
256:ths of the total size of the
metadata. The size is given as size-1.
That means that if this field is set
0, the request wants one 256:th of the
metadata.</td>
</tr>
</tbody>
</table>
<p>metadata:</p>
<table border="1" class="docutils">
<colgroup>
<col width="17%" />
<col width="23%" />
<col width="61%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">size</th>
<th class="head">name</th>
<th class="head">description</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>uint8_t</td>
<td>msg_type</td>
<td>1 means 'metadata'</td>
</tr>
<tr><td>int32_t</td>
<td>total_size</td>
<td>The total size of the metadata, given
in number of bytes.</td>
</tr>
<tr><td>int32_t</td>
<td>offset</td>
<td>The offset of where the metadata block
in this message belongs in the final
metadata. This is given in bytes.</td>
</tr>
<tr><td>uint8_t[]</td>
<td>metadata</td>
<td>The actual metadata block. The size of
this part is given implicit by the
length prefix in the bittorrent
protocol packet.</td>
</tr>
</tbody>
</table>
<p>Don't have metadata:</p>
<table border="1" class="docutils">
<colgroup>
<col width="17%" />
<col width="23%" />
<col width="61%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">size</th>
<th class="head">name</th>
<th class="head">description</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>uint8_t</td>
<td>msg_type</td>
<td>2 means 'I don't have metadata'.
This message is sent as a reply to a
metadata request if the the client
doesn't have any metadata.</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="dont-have">
<h2>dont_have</h2>
<p>Extension name: &quot;lt_donthave&quot;</p>
<p>The <tt class="docutils literal">dont_have</tt> extension message is used to tell peers that the client no
longer has a specific piece. The extension message should be advertised in the
<tt class="docutils literal">m</tt> dictionary as <tt class="docutils literal">lt_donthave</tt>. The message format mimics the regular
<tt class="docutils literal">HAVE</tt> bittorrent message.</p>
<p>Just like all extension messages, the first 2 bytes in the mssage itself are 20
(the bittorrent extension message) and the message ID assigned to this
extension in the <tt class="docutils literal">m</tt> dictionary in the handshake.</p>
<table border="1" class="docutils">
<colgroup>
<col width="17%" />
<col width="23%" />
<col width="61%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">size</th>
<th class="head">name</th>
<th class="head">description</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>uint32_t</td>
<td>piece</td>
<td>index of the piece the peer no longer
has.</td>
</tr>
</tbody>
</table>
<p>The length of this message (including the extension message prefix) is 6 bytes,
i.e. one byte longer than the normal <tt class="docutils literal">HAVE</tt> message, because of the extension
message wrapping.</p>
</div>
</div>
</div>
</body>
</html>

122
docs/extension_protocol.rst
View File

@ -200,3 +200,125 @@ 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.
extensions
==========
These extensions all operates within the `extension protocol`_. The name of the
extension is the name used in the extension-list packets, and the payload is
the data in the extended message (not counting the length-prefix, message-id
nor extension-id).
.. _`extension protocol`: extension_protocol.html
Note that since this protocol relies on one of the reserved bits in the
handshake, it may be incompatible with future versions of the mainline
bittorrent client.
These are the extensions that are currently implemented.
metadata from peers
-------------------
Extension name: "LT_metadata"
.. note::
This extension is deprecated in favor of the more widely supported
``ut_metadata`` extension, see `BEP 9`_.
The point with this extension is that you don't have to distribute the
metadata (.torrent-file) separately. The metadata can be distributed
through the bittorrent swarm. The only thing you need to download such
a torrent is the tracker url and the info-hash of the torrent.
It works by assuming that the initial seeder has the metadata and that the
metadata will propagate through the network as more peers join.
There are three kinds of messages in the metadata extension. These packets are
put as payload to the extension message. The three packets are:
* request metadata
* metadata
* don't have metadata
request metadata:
+-----------+---------------+----------------------------------------+
| size | name | description |
+===========+===============+========================================+
| uint8_t | msg_type | Determines the kind of message this is |
| | | 0 means 'request metadata' |
+-----------+---------------+----------------------------------------+
| uint8_t | start | The start of the metadata block that |
| | | is requested. It is given in 256:ths |
| | | of the total size of the metadata, |
| | | since the requesting client don't know |
| | | the size of the metadata. |
+-----------+---------------+----------------------------------------+
| uint8_t | size | The size of the metadata block that is |
| | | requested. This is also given in |
| | | 256:ths of the total size of the |
| | | metadata. The size is given as size-1. |
| | | That means that if this field is set |
| | | 0, the request wants one 256:th of the |
| | | metadata. |
+-----------+---------------+----------------------------------------+
metadata:
+-----------+---------------+----------------------------------------+
| size | name | description |
+===========+===============+========================================+
| uint8_t | msg_type | 1 means 'metadata' |
+-----------+---------------+----------------------------------------+
| int32_t | total_size | The total size of the metadata, given |
| | | in number of bytes. |
+-----------+---------------+----------------------------------------+
| int32_t | offset | The offset of where the metadata block |
| | | in this message belongs in the final |
| | | metadata. This is given in bytes. |
+-----------+---------------+----------------------------------------+
| uint8_t[] | metadata | The actual metadata block. The size of |
| | | this part is given implicit by the |
| | | length prefix in the bittorrent |
| | | protocol packet. |
+-----------+---------------+----------------------------------------+
Don't have metadata:
+-----------+---------------+----------------------------------------+
| size | name | description |
+===========+===============+========================================+
| uint8_t | msg_type | 2 means 'I don't have metadata'. |
| | | This message is sent as a reply to a |
| | | metadata request if the the client |
| | | doesn't have any metadata. |
+-----------+---------------+----------------------------------------+
.. _`BEP 9`: http://bittorrent.org/beps/bep_0009.html
dont_have
---------
Extension name: "lt_donthave"
The ``dont_have`` extension message is used to tell peers that the client no
longer has a specific piece. The extension message should be advertised in the
``m`` dictionary as ``lt_donthave``. The message format mimics the regular
``HAVE`` bittorrent message.
Just like all extension messages, the first 2 bytes in the mssage itself are 20
(the bittorrent extension message) and the message ID assigned to this
extension in the ``m`` dictionary in the handshake.
+-----------+---------------+----------------------------------------+
| size | name | description |
+===========+===============+========================================+
| uint32_t | piece | index of the piece the peer no longer |
| | | has. |
+-----------+---------------+----------------------------------------+
The length of this message (including the extension message prefix) is 6 bytes,
i.e. one byte longer than the normal ``HAVE`` message, because of the extension
message wrapping.

122
docs/manual.rst
View File

@ -516,129 +516,9 @@ allocating a new slot:
5. return **i** as the newly allocated slot.
extensions
==========
These extensions all operates within the `extension protocol`_. The name of the
extension is the name used in the extension-list packets, and the payload is
the data in the extended message (not counting the length-prefix, message-id
nor extension-id).
.. _`extension protocol`: extension_protocol.html
Note that since this protocol relies on one of the reserved bits in the
handshake, it may be incompatible with future versions of the mainline
bittorrent client.
These are the extensions that are currently implemented.
metadata from peers
-------------------
Extension name: "LT_metadata"
.. note::
This extension is deprecated in favor of the more widely supported
``ut_metadata`` extension, see `BEP 9`_.
The point with this extension is that you don't have to distribute the
metadata (.torrent-file) separately. The metadata can be distributed
through the bittorrent swarm. The only thing you need to download such
a torrent is the tracker url and the info-hash of the torrent.
It works by assuming that the initial seeder has the metadata and that the
metadata will propagate through the network as more peers join.
There are three kinds of messages in the metadata extension. These packets are
put as payload to the extension message. The three packets are:
* request metadata
* metadata
* don't have metadata
request metadata:
+-----------+---------------+----------------------------------------+
| size | name | description |
+===========+===============+========================================+
| uint8_t | msg_type | Determines the kind of message this is |
| | | 0 means 'request metadata' |
+-----------+---------------+----------------------------------------+
| uint8_t | start | The start of the metadata block that |
| | | is requested. It is given in 256:ths |
| | | of the total size of the metadata, |
| | | since the requesting client don't know |
| | | the size of the metadata. |
+-----------+---------------+----------------------------------------+
| uint8_t | size | The size of the metadata block that is |
| | | requested. This is also given in |
| | | 256:ths of the total size of the |
| | | metadata. The size is given as size-1. |
| | | That means that if this field is set |
| | | 0, the request wants one 256:th of the |
| | | metadata. |
+-----------+---------------+----------------------------------------+
metadata:
+-----------+---------------+----------------------------------------+
| size | name | description |
+===========+===============+========================================+
| uint8_t | msg_type | 1 means 'metadata' |
+-----------+---------------+----------------------------------------+
| int32_t | total_size | The total size of the metadata, given |
| | | in number of bytes. |
+-----------+---------------+----------------------------------------+
| int32_t | offset | The offset of where the metadata block |
| | | in this message belongs in the final |
| | | metadata. This is given in bytes. |
+-----------+---------------+----------------------------------------+
| uint8_t[] | metadata | The actual metadata block. The size of |
| | | this part is given implicit by the |
| | | length prefix in the bittorrent |
| | | protocol packet. |
+-----------+---------------+----------------------------------------+
Don't have metadata:
+-----------+---------------+----------------------------------------+
| size | name | description |
+===========+===============+========================================+
| uint8_t | msg_type | 2 means 'I don't have metadata'. |
| | | This message is sent as a reply to a |
| | | metadata request if the the client |
| | | doesn't have any metadata. |
+-----------+---------------+----------------------------------------+
.. _`BEP 9`: http://bittorrent.org/beps/bep_0009.html
dont_have
---------
Extension name: "lt_dont_have"
The ``dont_have`` extension message is used to tell peers that the client no
longer has a specific piece. The extension message should be advertised in the
``m`` dictionary as ``lt_dont_have``. The message format mimics the regular
``HAVE`` bittorrent message.
Just like all extension messages, the first 2 bytes in the mssage itself are 20
(the bittorrent extension message) and the message ID assigned to this
extension in the ``m`` dictionary in the handshake.
+-----------+---------------+----------------------------------------+
| size | name | description |
+===========+===============+========================================+
| uint32_t | piece | index of the piece the peer no longer |
| | | has. |
+-----------+---------------+----------------------------------------+
The length of this message (including the extension message prefix) is 6 bytes,
i.e. one byte longer than the normal ``HAVE`` message, because of the extension
message wrapping.
HTTP seeding
------------
============
There are two kinds of HTTP seeding. One with that assumes a smart (and polite)
client and one that assumes a smart server. These are specified in `BEP 19`_

72
docs/todo.html
View File

@ -81,7 +81,7 @@ do as well with NATs)</h2><h4>../src/session_impl.cpp:480</h4><pre style="backgr
m_udp_socket.subscribe(&amp;m_tracker_manager);
m_udp_socket.subscribe(&amp;m_utp_socket_manager);
</pre></td></tr><tr style="background: #f44"><td>relevance&nbsp;4</td><td><a href="javascript:expand(1)">../src/torrent.cpp:9550</a></td><td>this logic doesn't work for seeding torrents that are not ticked</td></tr><tr id="1" style="display: none;" colspan="3"><td colspan="3"><h2>this logic doesn't work for seeding torrents that are not ticked</h2><h4>../src/torrent.cpp:9550</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> {
</pre></td></tr><tr style="background: #f44"><td>relevance&nbsp;4</td><td><a href="javascript:expand(1)">../src/torrent.cpp:9560</a></td><td>this logic doesn't work for seeding torrents that are not ticked</td></tr><tr id="1" style="display: none;" colspan="3"><td colspan="3"><h2>this logic doesn't work for seeding torrents that are not ticked</h2><h4>../src/torrent.cpp:9560</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> {
i = m_connections.begin() + idx;
--idx;
}
@ -492,9 +492,9 @@ namespace libtorrent
}
h(ec, ce.addresses);
</pre></td></tr><tr style="background: #fcc"><td>relevance&nbsp;3</td><td><a href="javascript:expand(9)">../src/session_impl.cpp:5697</a></td><td>it would be really nice to update these counters as they are incremented. This depends on the session being ticked, which has a fairly coarse grained resolution</td></tr><tr id="9" style="display: none;" colspan="3"><td colspan="3"><h2>it would be really nice to update these counters
</pre></td></tr><tr style="background: #fcc"><td>relevance&nbsp;3</td><td><a href="javascript:expand(9)">../src/session_impl.cpp:5701</a></td><td>it would be really nice to update these counters as they are incremented. This depends on the session being ticked, which has a fairly coarse grained resolution</td></tr><tr id="9" style="display: none;" colspan="3"><td colspan="3"><h2>it would be really nice to update these counters
as they are incremented. This depends on the session
being ticked, which has a fairly coarse grained resolution</h2><h4>../src/session_impl.cpp:5697</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> t-&gt;status(&amp;alert-&gt;status.back(), ~torrent_handle::query_accurate_download_counters);
being ticked, which has a fairly coarse grained resolution</h2><h4>../src/session_impl.cpp:5701</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> t-&gt;status(&amp;alert-&gt;status.back(), ~torrent_handle::query_accurate_download_counters);
t-&gt;clear_in_state_update();
}
state_updates.clear();
@ -545,8 +545,8 @@ being ticked, which has a fairly coarse grained resolution</h2><h4>../src/sessio
for (int i = 0; i &lt; counters::num_counters; ++i)
values[i] = m_stats_counters[i];
</pre></td></tr><tr style="background: #fcc"><td>relevance&nbsp;3</td><td><a href="javascript:expand(10)">../src/session_impl.cpp:7156</a></td><td>If socket jobs could be higher level, to include RC4 encryption and decryption, we would offload the main thread even more</td></tr><tr id="10" style="display: none;" colspan="3"><td colspan="3"><h2>If socket jobs could be higher level, to include RC4 encryption and decryption,
we would offload the main thread even more</h2><h4>../src/session_impl.cpp:7156</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> {
</pre></td></tr><tr style="background: #fcc"><td>relevance&nbsp;3</td><td><a href="javascript:expand(10)">../src/session_impl.cpp:7160</a></td><td>If socket jobs could be higher level, to include RC4 encryption and decryption, we would offload the main thread even more</td></tr><tr id="10" style="display: none;" colspan="3"><td colspan="3"><h2>If socket jobs could be higher level, to include RC4 encryption and decryption,
we would offload the main thread even more</h2><h4>../src/session_impl.cpp:7160</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> {
int num_threads = m_settings.get_int(settings_pack::network_threads);
int num_pools = num_threads &gt; 0 ? num_threads : 1;
while (num_pools &gt; m_net_thread_pool.size())
@ -648,7 +648,7 @@ we would offload the main thread even more</h2><h4>../src/session_impl.cpp:7156<
alerts().post_alert(file_error_alert(j-&gt;error.ec
, resolve_filename(j-&gt;error.file), j-&gt;error.operation_str(), get_handle()));
if (c) c-&gt;disconnect(errors::no_memory, peer_connection_interface::op_file);
</pre></td></tr><tr style="background: #fcc"><td>relevance&nbsp;3</td><td><a href="javascript:expand(12)">../src/torrent.cpp:7594</a></td><td>if peer is a really good peer, maybe we shouldn't disconnect it</td></tr><tr id="12" style="display: none;" colspan="3"><td colspan="3"><h2>if peer is a really good peer, maybe we shouldn't disconnect it</h2><h4>../src/torrent.cpp:7594</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;">#if defined TORRENT_LOGGING || defined TORRENT_ERROR_LOGGING
</pre></td></tr><tr style="background: #fcc"><td>relevance&nbsp;3</td><td><a href="javascript:expand(12)">../src/torrent.cpp:7604</a></td><td>if peer is a really good peer, maybe we shouldn't disconnect it</td></tr><tr id="12" style="display: none;" colspan="3"><td colspan="3"><h2>if peer is a really good peer, maybe we shouldn't disconnect it</h2><h4>../src/torrent.cpp:7604</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;">#if defined TORRENT_LOGGING || defined TORRENT_ERROR_LOGGING
debug_log("incoming peer (%d)", int(m_connections.size()));
#endif
@ -1168,8 +1168,8 @@ settings_pack be optional?</h2><h4>../include/libtorrent/session.hpp:210</h4><pr
}
if (m_settings.get_int(settings_pack::peer_tos) != 0) {
</pre></td></tr><tr style="background: #cfc"><td>relevance&nbsp;2</td><td><a href="javascript:expand(23)">../src/session_impl.cpp:4596</a></td><td>make a list for torrents that want to be announced on the DHT so we don't have to loop over all torrents, just to find the ones that want to announce</td></tr><tr id="23" style="display: none;" colspan="3"><td colspan="3"><h2>make a list for torrents that want to be announced on the DHT so we
don't have to loop over all torrents, just to find the ones that want to announce</h2><h4>../src/session_impl.cpp:4596</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> if (!m_dht_torrents.empty())
</pre></td></tr><tr style="background: #cfc"><td>relevance&nbsp;2</td><td><a href="javascript:expand(23)">../src/session_impl.cpp:4600</a></td><td>make a list for torrents that want to be announced on the DHT so we don't have to loop over all torrents, just to find the ones that want to announce</td></tr><tr id="23" style="display: none;" colspan="3"><td colspan="3"><h2>make a list for torrents that want to be announced on the DHT so we
don't have to loop over all torrents, just to find the ones that want to announce</h2><h4>../src/session_impl.cpp:4600</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> if (!m_dht_torrents.empty())
{
boost::shared_ptr&lt;torrent&gt; t;
do
@ -1918,8 +1918,8 @@ the chunk headers should be subtracted from the receive_buffer_size</h2><h4>../s
std::string request;
request.reserve(400);
</pre></td></tr><tr style="background: #ccf"><td>relevance&nbsp;1</td><td><a href="javascript:expand(39)">../src/session_impl.cpp:6508</a></td><td>report the proper address of the router as the source IP of this understanding of our external address, instead of the empty address</td></tr><tr id="39" style="display: none;" colspan="3"><td colspan="3"><h2>report the proper address of the router as the source IP of
this understanding of our external address, instead of the empty address</h2><h4>../src/session_impl.cpp:6508</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> void session_impl::on_port_mapping(int mapping, address const&amp; ip, int port
</pre></td></tr><tr style="background: #ccf"><td>relevance&nbsp;1</td><td><a href="javascript:expand(39)">../src/session_impl.cpp:6512</a></td><td>report the proper address of the router as the source IP of this understanding of our external address, instead of the empty address</td></tr><tr id="39" style="display: none;" colspan="3"><td colspan="3"><h2>report the proper address of the router as the source IP of
this understanding of our external address, instead of the empty address</h2><h4>../src/session_impl.cpp:6512</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> void session_impl::on_port_mapping(int mapping, address const&amp; ip, int port
, error_code const&amp; ec, int map_transport)
{
TORRENT_ASSERT(is_single_thread());
@ -1970,9 +1970,9 @@ this understanding of our external address, instead of the empty address</h2><h4
{
// INVARIANT_CHECK;
TORRENT_ASSERT(is_single_thread());
</pre></td></tr><tr style="background: #ccf"><td>relevance&nbsp;1</td><td><a href="javascript:expand(40)">../src/session_impl.cpp:7668</a></td><td>we only need to do this if our global IPv4 address has changed since the DHT (currently) only supports IPv4. Since restarting the DHT is kind of expensive, it would be nice to not do it unnecessarily</td></tr><tr id="40" style="display: none;" colspan="3"><td colspan="3"><h2>we only need to do this if our global IPv4 address has changed
</pre></td></tr><tr style="background: #ccf"><td>relevance&nbsp;1</td><td><a href="javascript:expand(40)">../src/session_impl.cpp:7672</a></td><td>we only need to do this if our global IPv4 address has changed since the DHT (currently) only supports IPv4. Since restarting the DHT is kind of expensive, it would be nice to not do it unnecessarily</td></tr><tr id="40" style="display: none;" colspan="3"><td colspan="3"><h2>we only need to do this if our global IPv4 address has changed
since the DHT (currently) only supports IPv4. Since restarting the DHT
is kind of expensive, it would be nice to not do it unnecessarily</h2><h4>../src/session_impl.cpp:7668</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;">#endif
is kind of expensive, it would be nice to not do it unnecessarily</h2><h4>../src/session_impl.cpp:7672</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;">#endif
if (!m_external_ip.cast_vote(ip, source_type, source)) return;
@ -2130,9 +2130,9 @@ it may pose an issue when downgrading though</h2><h4>../src/torrent.cpp:6774</h4
// write have bitmask
// the pieces string has one byte per piece. Each
// byte is a bitmask representing different properties
</pre></td></tr><tr style="background: #ccf"><td>relevance&nbsp;1</td><td><a href="javascript:expand(43)">../src/torrent.cpp:7842</a></td><td>should disconnect all peers that have the pieces we have not just seeds. It would be pretty expensive to check all pieces for all peers though</td></tr><tr id="43" style="display: none;" colspan="3"><td colspan="3"><h2>should disconnect all peers that have the pieces we have
</pre></td></tr><tr style="background: #ccf"><td>relevance&nbsp;1</td><td><a href="javascript:expand(43)">../src/torrent.cpp:7852</a></td><td>should disconnect all peers that have the pieces we have not just seeds. It would be pretty expensive to check all pieces for all peers though</td></tr><tr id="43" style="display: none;" colspan="3"><td colspan="3"><h2>should disconnect all peers that have the pieces we have
not just seeds. It would be pretty expensive to check all pieces
for all peers though</h2><h4>../src/torrent.cpp:7842</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> set_state(torrent_status::finished);
for all peers though</h2><h4>../src/torrent.cpp:7852</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> set_state(torrent_status::finished);
set_queue_position(-1);
m_became_finished = m_ses.session_time();
@ -3530,7 +3530,7 @@ retry:
if (s.sock)
{
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(71)">../src/session_impl.cpp:3225</a></td><td>should this function take a shared_ptr instead?</td></tr><tr id="71" style="display: none;" colspan="3"><td colspan="3"><h2>should this function take a shared_ptr instead?</h2><h4>../src/session_impl.cpp:3225</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> {
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(71)">../src/session_impl.cpp:3229</a></td><td>should this function take a shared_ptr instead?</td></tr><tr id="71" style="display: none;" colspan="3"><td colspan="3"><h2>should this function take a shared_ptr instead?</h2><h4>../src/session_impl.cpp:3229</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> {
#if defined TORRENT_ASIO_DEBUGGING
complete_async("session_impl::on_socks_accept");
#endif
@ -3581,7 +3581,7 @@ retry:
TORRENT_ASSERT(p-&gt;is_disconnecting());
if (!p-&gt;is_choked() &amp;&amp; !p-&gt;ignore_unchoke_slots()) --m_num_unchoked;
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(72)">../src/session_impl.cpp:3600</a></td><td>have a separate list for these connections, instead of having to loop through all of them</td></tr><tr id="72" style="display: none;" colspan="3"><td colspan="3"><h2>have a separate list for these connections, instead of having to loop through all of them</h2><h4>../src/session_impl.cpp:3600</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> if (m_auto_manage_time_scaler &lt; 0)
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(72)">../src/session_impl.cpp:3604</a></td><td>have a separate list for these connections, instead of having to loop through all of them</td></tr><tr id="72" style="display: none;" colspan="3"><td colspan="3"><h2>have a separate list for these connections, instead of having to loop through all of them</h2><h4>../src/session_impl.cpp:3604</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> if (m_auto_manage_time_scaler &lt; 0)
{
INVARIANT_CHECK;
m_auto_manage_time_scaler = settings().get_int(settings_pack::auto_manage_interval);
@ -3632,7 +3632,7 @@ retry:
#ifndef TORRENT_DISABLE_DHT
if (m_dht)
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(73)">../src/session_impl.cpp:3641</a></td><td>this should apply to all bandwidth channels</td></tr><tr id="73" style="display: none;" colspan="3"><td colspan="3"><h2>this should apply to all bandwidth channels</h2><h4>../src/session_impl.cpp:3641</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> t.second_tick(tick_interval_ms, m_tick_residual / 1000);
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(73)">../src/session_impl.cpp:3645</a></td><td>this should apply to all bandwidth channels</td></tr><tr id="73" style="display: none;" colspan="3"><td colspan="3"><h2>this should apply to all bandwidth channels</h2><h4>../src/session_impl.cpp:3645</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> t.second_tick(tick_interval_ms, m_tick_residual / 1000);
// if the call to second_tick caused the torrent
// to no longer want to be ticked (i.e. it was
@ -3683,7 +3683,7 @@ retry:
&amp;&amp; m_stat.upload_ip_overhead() &gt;= up_limit
&amp;&amp; m_alerts.should_post&lt;performance_alert&gt;())
{
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(74)">../src/session_impl.cpp:4704</a></td><td>these vectors could be copied from m_torrent_lists, if we would maintain them. That way the first pass over all torrents could be avoided. It would be especially efficient if most torrents are not auto-managed whenever we receive a scrape response (or anything that may change the rank of a torrent) that one torrent could re-sort itself in a list that's kept sorted at all times. That way, this pass over all torrents could be avoided alltogether.</td></tr><tr id="74" style="display: none;" colspan="3"><td colspan="3"><h2>these vectors could be copied from m_torrent_lists,
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(74)">../src/session_impl.cpp:4708</a></td><td>these vectors could be copied from m_torrent_lists, if we would maintain them. That way the first pass over all torrents could be avoided. It would be especially efficient if most torrents are not auto-managed whenever we receive a scrape response (or anything that may change the rank of a torrent) that one torrent could re-sort itself in a list that's kept sorted at all times. That way, this pass over all torrents could be avoided alltogether.</td></tr><tr id="74" style="display: none;" colspan="3"><td colspan="3"><h2>these vectors could be copied from m_torrent_lists,
if we would maintain them. That way the first pass over
all torrents could be avoided. It would be especially
efficient if most torrents are not auto-managed
@ -3691,7 +3691,7 @@ whenever we receive a scrape response (or anything
that may change the rank of a torrent) that one torrent
could re-sort itself in a list that's kept sorted at all
times. That way, this pass over all torrents could be
avoided alltogether.</h2><h4>../src/session_impl.cpp:4704</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;">#if defined TORRENT_VERBOSE_LOGGING || defined TORRENT_LOGGING
avoided alltogether.</h2><h4>../src/session_impl.cpp:4708</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;">#if defined TORRENT_VERBOSE_LOGGING || defined TORRENT_LOGGING
if (t-&gt;allows_peers())
t-&gt;log_to_all_peers("AUTO MANAGER PAUSING TORRENT");
#endif
@ -3742,7 +3742,7 @@ avoided alltogether.</h2><h4>../src/session_impl.cpp:4704</h4><pre style="backgr
for (torrent_map::iterator i = m_torrents.begin()
, end(m_torrents.end()); i != end; ++i)
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(75)">../src/session_impl.cpp:4779</a></td><td>allow extensions to sort torrents for queuing</td></tr><tr id="75" style="display: none;" colspan="3"><td colspan="3"><h2>allow extensions to sort torrents for queuing</h2><h4>../src/session_impl.cpp:4779</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> if (t-&gt;is_finished())
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(75)">../src/session_impl.cpp:4783</a></td><td>allow extensions to sort torrents for queuing</td></tr><tr id="75" style="display: none;" colspan="3"><td colspan="3"><h2>allow extensions to sort torrents for queuing</h2><h4>../src/session_impl.cpp:4783</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> if (t-&gt;is_finished())
seeds.push_back(t);
else
downloaders.push_back(t);
@ -3793,9 +3793,9 @@ avoided alltogether.</h2><h4>../src/session_impl.cpp:4704</h4><pre style="backgr
, hard_limit, num_downloaders);
auto_manage_torrents(seeds, checking_limit, dht_limit, tracker_limit, lsd_limit
, hard_limit, num_seeds);
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(76)">../src/session_impl.cpp:4957</a></td><td>use a lower limit than m_settings.connections_limit to allocate the to 10% or so of connection slots for incoming connections</td></tr><tr id="76" style="display: none;" colspan="3"><td colspan="3"><h2>use a lower limit than m_settings.connections_limit
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(76)">../src/session_impl.cpp:4961</a></td><td>use a lower limit than m_settings.connections_limit to allocate the to 10% or so of connection slots for incoming connections</td></tr><tr id="76" style="display: none;" colspan="3"><td colspan="3"><h2>use a lower limit than m_settings.connections_limit
to allocate the to 10% or so of connection slots for incoming
connections</h2><h4>../src/session_impl.cpp:4957</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> // if we don't have any free slots, return
connections</h2><h4>../src/session_impl.cpp:4961</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> // if we don't have any free slots, return
if (free_slots &lt;= -m_half_open.limit()) return;
// boost connections are connections made by torrent connection
@ -3846,8 +3846,8 @@ connections</h2><h4>../src/session_impl.cpp:4957</h4><pre style="background: #f6
m_next_finished_connect_torrent = 0;
torrent* t = NULL;
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(77)">../src/session_impl.cpp:5119</a></td><td>post a message to have this happen immediately instead of waiting for the next tick</td></tr><tr id="77" style="display: none;" colspan="3"><td colspan="3"><h2>post a message to have this happen
immediately instead of waiting for the next tick</h2><h4>../src/session_impl.cpp:5119</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> {
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(77)">../src/session_impl.cpp:5123</a></td><td>post a message to have this happen immediately instead of waiting for the next tick</td></tr><tr id="77" style="display: none;" colspan="3"><td colspan="3"><h2>post a message to have this happen
immediately instead of waiting for the next tick</h2><h4>../src/session_impl.cpp:5123</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> {
// we've unchoked this peer, and it hasn't reciprocated
// we may want to increase our estimated reciprocation rate
p-&gt;increase_est_reciprocation_rate();
@ -3898,7 +3898,7 @@ immediately instead of waiting for the next tick</h2><h4>../src/session_impl.cpp
prev = i;
}
#endif
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(78)">../src/session_impl.cpp:5153</a></td><td>make configurable</td></tr><tr id="78" style="display: none;" colspan="3"><td colspan="3"><h2>make configurable</h2><h4>../src/session_impl.cpp:5153</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;">
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(78)">../src/session_impl.cpp:5157</a></td><td>make configurable</td></tr><tr id="78" style="display: none;" colspan="3"><td colspan="3"><h2>make configurable</h2><h4>../src/session_impl.cpp:5157</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;">
#ifdef TORRENT_DEBUG
for (std::vector&lt;peer_connection*&gt;::const_iterator i = peers.begin()
, end(peers.end()), prev(peers.end()); i != end; ++i)
@ -3931,7 +3931,7 @@ immediately instead of waiting for the next tick</h2><h4>../src/session_impl.cpp
++m_allowed_upload_slots;
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(79)">../src/session_impl.cpp:5167</a></td><td>make configurable</td></tr><tr id="79" style="display: none;" colspan="3"><td colspan="3"><h2>make configurable</h2><h4>../src/session_impl.cpp:5167</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> &gt;= (*i)-&gt;uploaded_in_last_round() * 1000
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(79)">../src/session_impl.cpp:5171</a></td><td>make configurable</td></tr><tr id="79" style="display: none;" colspan="3"><td colspan="3"><h2>make configurable</h2><h4>../src/session_impl.cpp:5171</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> &gt;= (*i)-&gt;uploaded_in_last_round() * 1000
* (1 + t2-&gt;priority()) / total_milliseconds(unchoke_interval));
}
prev = i;
@ -3982,7 +3982,7 @@ immediately instead of waiting for the next tick</h2><h4>../src/session_impl.cpp
{
// if our current upload rate is less than 90% of our
// limit
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(80)">../src/session_impl.cpp:5246</a></td><td>this should be called for all peers!</td></tr><tr id="80" style="display: none;" colspan="3"><td colspan="3"><h2>this should be called for all peers!</h2><h4>../src/session_impl.cpp:5246</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> // measurement of the peak, use that + 10kB/s, otherwise
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(80)">../src/session_impl.cpp:5250</a></td><td>this should be called for all peers!</td></tr><tr id="80" style="display: none;" colspan="3"><td colspan="3"><h2>this should be called for all peers!</h2><h4>../src/session_impl.cpp:5250</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> // measurement of the peak, use that + 10kB/s, otherwise
// assume 20 kB/s
upload_capacity_left = (std::max)(20000, m_peak_up_rate + 10000);
if (m_alerts.should_post&lt;performance_alert&gt;())
@ -4033,10 +4033,10 @@ immediately instead of waiting for the next tick</h2><h4>../src/session_impl.cpp
--unchoke_set_size;
++m_num_unchoked;
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(81)">../src/session_impl.cpp:5663</a></td><td>it might be a nice feature here to limit the number of torrents to send in a single update. By just posting the first n torrents, they would nicely be round-robined because the torrent lists are always pushed back</td></tr><tr id="81" style="display: none;" colspan="3"><td colspan="3"><h2>it might be a nice feature here to limit the number of torrents
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(81)">../src/session_impl.cpp:5667</a></td><td>it might be a nice feature here to limit the number of torrents to send in a single update. By just posting the first n torrents, they would nicely be round-robined because the torrent lists are always pushed back</td></tr><tr id="81" style="display: none;" colspan="3"><td colspan="3"><h2>it might be a nice feature here to limit the number of torrents
to send in a single update. By just posting the first n torrents, they
would nicely be round-robined because the torrent lists are always
pushed back</h2><h4>../src/session_impl.cpp:5663</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> t-&gt;status(&amp;*i, flags);
pushed back</h2><h4>../src/session_impl.cpp:5667</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> t-&gt;status(&amp;*i, flags);
}
}
@ -4831,9 +4831,9 @@ using file_base</h2><h4>../src/torrent.cpp:6831</h4><pre style="background: #f6f
, end(m_policy-&gt;end_peer()); i != end; ++i)
{
error_code ec;
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(96)">../src/torrent.cpp:8790</a></td><td>add a flag to ignore stats, and only care about resume data for content. For unchanged files, don't trigger a load of the metadata just to save an empty resume data file</td></tr><tr id="96" style="display: none;" colspan="3"><td colspan="3"><h2>add a flag to ignore stats, and only care about resume data for
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(96)">../src/torrent.cpp:8800</a></td><td>add a flag to ignore stats, and only care about resume data for content. For unchanged files, don't trigger a load of the metadata just to save an empty resume data file</td></tr><tr id="96" style="display: none;" colspan="3"><td colspan="3"><h2>add a flag to ignore stats, and only care about resume data for
content. For unchanged files, don't trigger a load of the metadata
just to save an empty resume data file</h2><h4>../src/torrent.cpp:8790</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> if (m_complete != 0xffffff) seeds = m_complete;
just to save an empty resume data file</h2><h4>../src/torrent.cpp:8800</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> if (m_complete != 0xffffff) seeds = m_complete;
else seeds = m_policy ? m_policy-&gt;num_seeds() : 0;
if (m_incomplete != 0xffffff) downloaders = m_incomplete;
@ -4884,10 +4884,10 @@ just to save an empty resume data file</h2><h4>../src/torrent.cpp:8790</h4><pre
m_save_resume_flags = boost::uint8_t(flags);
state_updated();
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(97)">../src/torrent.cpp:9758</a></td><td>go through the pieces we have and count the total number of downloaders we have. Only count peers that are interested in us since some peers might not send have messages for pieces we have it num_interested == 0, we need to pick a new piece</td></tr><tr id="97" style="display: none;" colspan="3"><td colspan="3"><h2>go through the pieces we have and count the total number
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(97)">../src/torrent.cpp:9768</a></td><td>go through the pieces we have and count the total number of downloaders we have. Only count peers that are interested in us since some peers might not send have messages for pieces we have it num_interested == 0, we need to pick a new piece</td></tr><tr id="97" style="display: none;" colspan="3"><td colspan="3"><h2>go through the pieces we have and count the total number
of downloaders we have. Only count peers that are interested in us
since some peers might not send have messages for pieces we have
it num_interested == 0, we need to pick a new piece</h2><h4>../src/torrent.cpp:9758</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> }
it num_interested == 0, we need to pick a new piece</h2><h4>../src/torrent.cpp:9768</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> }
rarest_pieces.clear();
rarest_rarity = pp.peer_count;
@ -4938,8 +4938,8 @@ it num_interested == 0, we need to pick a new piece</h2><h4>../src/torrent.cpp:9
if (num_cache_pieces &gt; m_torrent_file-&gt;num_pieces())
num_cache_pieces = m_torrent_file-&gt;num_pieces();
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(98)">../src/torrent.cpp:10404</a></td><td>instead of resorting the whole list, insert the peers directly into the right place</td></tr><tr id="98" style="display: none;" colspan="3"><td colspan="3"><h2>instead of resorting the whole list, insert the peers
directly into the right place</h2><h4>../src/torrent.cpp:10404</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> printf("timed out [average-piece-time: %d ms ]\n"
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(98)">../src/torrent.cpp:10414</a></td><td>instead of resorting the whole list, insert the peers directly into the right place</td></tr><tr id="98" style="display: none;" colspan="3"><td colspan="3"><h2>instead of resorting the whole list, insert the peers
directly into the right place</h2><h4>../src/torrent.cpp:10414</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> printf("timed out [average-piece-time: %d ms ]\n"
, m_average_piece_time);
#endif
}
@ -6055,7 +6055,7 @@ m_sock.bind(endpoint, ec);</h2><h4>../include/libtorrent/proxy_base.hpp:166</h4>
m_sock.close(ec);
m_resolver.cancel();
}
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(120)">../include/libtorrent/session.hpp:856</a></td><td>add get_peer_class_type_filter() as well</td></tr><tr id="120" style="display: none;" colspan="3"><td colspan="3"><h2>add get_peer_class_type_filter() as well</h2><h4>../include/libtorrent/session.hpp:856</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> //
</pre></td></tr><tr style="background: #ccc"><td>relevance&nbsp;0</td><td><a href="javascript:expand(120)">../include/libtorrent/session.hpp:857</a></td><td>add get_peer_class_type_filter() as well</td></tr><tr id="120" style="display: none;" colspan="3"><td colspan="3"><h2>add get_peer_class_type_filter() as well</h2><h4>../include/libtorrent/session.hpp:857</h4><pre style="background: #f6f6f6; border: solid 1px #ddd;"> //
// The ``peer_class`` argument cannot be greater than 31. The bitmasks
// representing peer classes in the ``peer_class_filter`` are 32 bits.
//