From 4fcfaee438ed87ea49e1a13f689cfa7bd31bcf5a Mon Sep 17 00:00:00 2001 From: Arvid Norberg Date: Wed, 3 Sep 2014 22:28:28 +0000 Subject: [PATCH] merged changes from RC_1_0 --- docs/extension_protocol.html | 169 +++++++++++++++++++++++++++++++++++ docs/extension_protocol.rst | 122 +++++++++++++++++++++++++ docs/manual.rst | 122 +------------------------ docs/todo.html | 72 +++++++-------- 4 files changed, 328 insertions(+), 157 deletions(-) diff --git a/docs/extension_protocol.html b/docs/extension_protocol.html index 92727e845..fb84020fb 100644 --- a/docs/extension_protocol.html +++ b/docs/extension_protocol.html @@ -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.

+
+

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).

+

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:

+ +++++ + + + + + + + + + + + + + + + + + + + + +
sizenamedescription
uint8_tmsg_typeDetermines the kind of message this is +0 means 'request metadata'
uint8_tstartThe 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_tsizeThe 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:

+ +++++ + + + + + + + + + + + + + + + + + + + + + + + + +
sizenamedescription
uint8_tmsg_type1 means 'metadata'
int32_ttotal_sizeThe total size of the metadata, given +in number of bytes.
int32_toffsetThe offset of where the metadata block +in this message belongs in the final +metadata. This is given in bytes.
uint8_t[]metadataThe actual metadata block. The size of +this part is given implicit by the +length prefix in the bittorrent +protocol packet.
+

Don't have metadata:

+ +++++ + + + + + + + + + + + + +
sizenamedescription
uint8_tmsg_type2 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.
+
+
+

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.

+ +++++ + + + + + + + + + + + + +
sizenamedescription
uint32_tpieceindex 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.

+
+
diff --git a/docs/extension_protocol.rst b/docs/extension_protocol.rst index ac8c09f90..b1aa0baf6 100644 --- a/docs/extension_protocol.rst +++ b/docs/extension_protocol.rst @@ -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. + diff --git a/docs/manual.rst b/docs/manual.rst index db3b1bdd4..41614a074 100644 --- a/docs/manual.rst +++ b/docs/manual.rst @@ -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`_ diff --git a/docs/todo.html b/docs/todo.html index bc87f2dbe..a16d9fbaa 100644 --- a/docs/todo.html +++ b/docs/todo.html @@ -81,7 +81,7 @@ do as well with NATs)

../src/session_impl.cpp:480

relevance 4../src/torrent.cpp:9550this logic doesn't work for seeding torrents that are not ticked
this logic doesn't work for seeding torrents that are not ticked
../src/torrent.cpp:9550
			{
+
relevance 4../src/torrent.cpp:9560this logic doesn't work for seeding torrents that are not ticked
this logic doesn't work for seeding torrents that are not ticked
../src/torrent.cpp:9560
			{
 				i = m_connections.begin() + idx;
 				--idx;
 			}
@@ -492,9 +492,9 @@ namespace libtorrent
 		}
 
 		h(ec, ce.addresses);
-
relevance 3../src/session_impl.cpp:5697it 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
it would be really nice to update these counters
+
relevance 3../src/session_impl.cpp:5701it 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

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

../src/session_impl.cpp:5697

			t->status(&alert->status.back(), ~torrent_handle::query_accurate_download_counters);
+being ticked, which has a fairly coarse grained resolution
../src/session_impl.cpp:5701
			t->status(&alert->status.back(), ~torrent_handle::query_accurate_download_counters);
 			t->clear_in_state_update();
 		}
 		state_updates.clear();
@@ -545,8 +545,8 @@ being ticked, which has a fairly coarse grained resolution
../src/sessio
 		for (int i = 0; i < counters::num_counters; ++i)
 			values[i] = m_stats_counters[i];
 
-
relevance 3../src/session_impl.cpp:7156If socket jobs could be higher level, to include RC4 encryption and decryption, we would offload the main thread even more
If socket jobs could be higher level, to include RC4 encryption and decryption,
-we would offload the main thread even more
../src/session_impl.cpp:7156
	{
+
relevance 3../src/session_impl.cpp:7160If socket jobs could be higher level, to include RC4 encryption and decryption, we would offload the main thread even more
If socket jobs could be higher level, to include RC4 encryption and decryption,
+we would offload the main thread even more
../src/session_impl.cpp:7160
	{
 		int num_threads = m_settings.get_int(settings_pack::network_threads);
 		int num_pools = num_threads > 0 ? num_threads : 1;
 		while (num_pools > m_net_thread_pool.size())
@@ -648,7 +648,7 @@ we would offload the main thread even more
../src/session_impl.cpp:7156<
 				alerts().post_alert(file_error_alert(j->error.ec
 					, resolve_filename(j->error.file), j->error.operation_str(), get_handle()));
 			if (c) c->disconnect(errors::no_memory, peer_connection_interface::op_file);
-
relevance 3../src/torrent.cpp:7594if peer is a really good peer, maybe we shouldn't disconnect it
if peer is a really good peer, maybe we shouldn't disconnect it
../src/torrent.cpp:7594
#if defined TORRENT_LOGGING || defined TORRENT_ERROR_LOGGING
+
relevance 3../src/torrent.cpp:7604if peer is a really good peer, maybe we shouldn't disconnect it
if peer is a really good peer, maybe we shouldn't disconnect it
../src/torrent.cpp:7604
#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?
../include/libtorrent/session.hpp:210
relevance 2../src/session_impl.cpp:4596make 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
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
../src/session_impl.cpp:4596
		if (!m_dht_torrents.empty())
+
relevance 2../src/session_impl.cpp:4600make 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
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
../src/session_impl.cpp:4600
		if (!m_dht_torrents.empty())
 		{
 			boost::shared_ptr<torrent> t;
 			do
@@ -1918,8 +1918,8 @@ the chunk headers should be subtracted from the receive_buffer_size
../s
 		std::string request;
 		request.reserve(400);
 
-
relevance 1../src/session_impl.cpp:6508report the proper address of the router as the source IP of this understanding of our external address, instead of the empty address
report the proper address of the router as the source IP of
-this understanding of our external address, instead of the empty address
../src/session_impl.cpp:6508
	void session_impl::on_port_mapping(int mapping, address const& ip, int port
+
relevance 1../src/session_impl.cpp:6512report the proper address of the router as the source IP of this understanding of our external address, instead of the empty address
report the proper address of the router as the source IP of
+this understanding of our external address, instead of the empty address
../src/session_impl.cpp:6512
	void session_impl::on_port_mapping(int mapping, address const& ip, int port
 		, error_code const& ec, int map_transport)
 	{
 		TORRENT_ASSERT(is_single_thread());
@@ -1970,9 +1970,9 @@ this understanding of our external address, instead of the empty address
relevance 1../src/session_impl.cpp:7668we 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
we only need to do this if our global IPv4 address has changed
+
relevance 1../src/session_impl.cpp:7672we 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
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
../src/session_impl.cpp:7668
#endif
+is kind of expensive, it would be nice to not do it unnecessarily
../src/session_impl.cpp:7672
#endif
 
 		if (!m_external_ip.cast_vote(ip, source_type, source)) return;
 
@@ -2130,9 +2130,9 @@ it may pose an issue when downgrading though
../src/torrent.cpp:6774
relevance 1../src/torrent.cpp:7842should 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
should disconnect all peers that have the pieces we have
+
relevance 1../src/torrent.cpp:7852should 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
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
../src/torrent.cpp:7842
		set_state(torrent_status::finished);
+for all peers though
../src/torrent.cpp:7852
		set_state(torrent_status::finished);
 		set_queue_position(-1);
 
 		m_became_finished = m_ses.session_time();
@@ -3530,7 +3530,7 @@ retry:
 
 				if (s.sock)
 				{
-
relevance 0../src/session_impl.cpp:3225should this function take a shared_ptr instead?
should this function take a shared_ptr instead?
../src/session_impl.cpp:3225
	{
+
relevance 0../src/session_impl.cpp:3229should this function take a shared_ptr instead?
should this function take a shared_ptr instead?
../src/session_impl.cpp:3229
	{
 #if defined TORRENT_ASIO_DEBUGGING
 		complete_async("session_impl::on_socks_accept");
 #endif
@@ -3581,7 +3581,7 @@ retry:
 		TORRENT_ASSERT(p->is_disconnecting());
 
 		if (!p->is_choked() && !p->ignore_unchoke_slots()) --m_num_unchoked;
-
relevance 0../src/session_impl.cpp:3600have a separate list for these connections, instead of having to loop through all of them
have a separate list for these connections, instead of having to loop through all of them
../src/session_impl.cpp:3600
		if (m_auto_manage_time_scaler < 0)
+
relevance 0../src/session_impl.cpp:3604have a separate list for these connections, instead of having to loop through all of them
have a separate list for these connections, instead of having to loop through all of them
../src/session_impl.cpp:3604
		if (m_auto_manage_time_scaler < 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)
-
relevance 0../src/session_impl.cpp:3641this should apply to all bandwidth channels
this should apply to all bandwidth channels
../src/session_impl.cpp:3641
			t.second_tick(tick_interval_ms, m_tick_residual / 1000);
+
relevance 0../src/session_impl.cpp:3645this should apply to all bandwidth channels
this should apply to all bandwidth channels
../src/session_impl.cpp:3645
			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:
 				&& m_stat.upload_ip_overhead() >= up_limit
 				&& m_alerts.should_post<performance_alert>())
 			{
-
relevance 0../src/session_impl.cpp:4704these 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.
these vectors could be copied from m_torrent_lists,
+
relevance 0../src/session_impl.cpp:4708these 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.
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.
../src/session_impl.cpp:4704
#if defined TORRENT_VERBOSE_LOGGING || defined TORRENT_LOGGING
+avoided alltogether.
../src/session_impl.cpp:4708
#if defined TORRENT_VERBOSE_LOGGING || defined TORRENT_LOGGING
 				if (t->allows_peers())
 					t->log_to_all_peers("AUTO MANAGER PAUSING TORRENT");
 #endif
@@ -3742,7 +3742,7 @@ avoided alltogether.
../src/session_impl.cpp:4704
relevance 0../src/session_impl.cpp:4779allow extensions to sort torrents for queuing
allow extensions to sort torrents for queuing
../src/session_impl.cpp:4779
				if (t->is_finished())
+
relevance 0../src/session_impl.cpp:4783allow extensions to sort torrents for queuing
allow extensions to sort torrents for queuing
../src/session_impl.cpp:4783
				if (t->is_finished())
 					seeds.push_back(t);
 				else
 					downloaders.push_back(t);
@@ -3793,9 +3793,9 @@ avoided alltogether.
../src/session_impl.cpp:4704
relevance 0../src/session_impl.cpp:4957use a lower limit than m_settings.connections_limit to allocate the to 10% or so of connection slots for incoming connections
use a lower limit than m_settings.connections_limit
+
relevance 0../src/session_impl.cpp:4961use a lower limit than m_settings.connections_limit to allocate the to 10% or so of connection slots for incoming connections
use a lower limit than m_settings.connections_limit
 to allocate the to 10% or so of connection slots for incoming
-connections
../src/session_impl.cpp:4957
		// if we don't have any free slots, return
+connections
../src/session_impl.cpp:4961
		// if we don't have any free slots, return
 		if (free_slots <= -m_half_open.limit()) return;
 
 		// boost connections are connections made by torrent connection
@@ -3846,8 +3846,8 @@ connections
../src/session_impl.cpp:4957
relevance 0../src/session_impl.cpp:5119post a message to have this happen immediately instead of waiting for the next tick
post a message to have this happen
-immediately instead of waiting for the next tick
../src/session_impl.cpp:5119
					{
+
relevance 0../src/session_impl.cpp:5123post a message to have this happen immediately instead of waiting for the next tick
post a message to have this happen
+immediately instead of waiting for the next tick
../src/session_impl.cpp:5123
					{
 						// we've unchoked this peer, and it hasn't reciprocated
 						// we may want to increase our estimated reciprocation rate
 						p->increase_est_reciprocation_rate();
@@ -3898,7 +3898,7 @@ immediately instead of waiting for the next tick
../src/session_impl.cpp
 				prev = i;
 			}
 #endif
-
relevance 0../src/session_impl.cpp:5153make configurable
make configurable
../src/session_impl.cpp:5153
+
relevance 0../src/session_impl.cpp:5157make configurable
make configurable
../src/session_impl.cpp:5157
 #ifdef TORRENT_DEBUG
 			for (std::vector<peer_connection*>::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
../src/session_impl.cpp
 
 				++m_allowed_upload_slots;
 
-
relevance 0../src/session_impl.cpp:5167make configurable
make configurable
../src/session_impl.cpp:5167
						>= (*i)->uploaded_in_last_round() * 1000
+
relevance 0../src/session_impl.cpp:5171make configurable
make configurable
../src/session_impl.cpp:5171
						>= (*i)->uploaded_in_last_round() * 1000
 						* (1 + t2->priority()) / total_milliseconds(unchoke_interval));
 				}
 				prev = i;
@@ -3982,7 +3982,7 @@ immediately instead of waiting for the next tick
../src/session_impl.cpp
 		{
 			// if our current upload rate is less than 90% of our 
 			// limit
-
relevance 0../src/session_impl.cpp:5246this should be called for all peers!
this should be called for all peers!
../src/session_impl.cpp:5246
				// measurement of the peak, use that + 10kB/s, otherwise
+
relevance 0../src/session_impl.cpp:5250this should be called for all peers!
this should be called for all peers!
../src/session_impl.cpp:5250
				// 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<performance_alert>())
@@ -4033,10 +4033,10 @@ immediately instead of waiting for the next tick
../src/session_impl.cpp
 				--unchoke_set_size;
 				++m_num_unchoked;
 
-
relevance 0../src/session_impl.cpp:5663it 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
it might be a nice feature here to limit the number of torrents
+
relevance 0../src/session_impl.cpp:5667it 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
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
../src/session_impl.cpp:5663
			t->status(&*i, flags);
+pushed back
../src/session_impl.cpp:5667
			t->status(&*i, flags);
 		}
 	}
 	
@@ -4831,9 +4831,9 @@ using file_base
../src/torrent.cpp:6831
relevance 0../src/torrent.cpp:8790add 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
add a flag to ignore stats, and only care about resume data for
+
relevance 0../src/torrent.cpp:8800add 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
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
../src/torrent.cpp:8790
		if (m_complete != 0xffffff) seeds = m_complete;
+just to save an empty resume data file
../src/torrent.cpp:8800
		if (m_complete != 0xffffff) seeds = m_complete;
 		else seeds = m_policy ? m_policy->num_seeds() : 0;
 
 		if (m_incomplete != 0xffffff) downloaders = m_incomplete;
@@ -4884,10 +4884,10 @@ just to save an empty resume data file
../src/torrent.cpp:8790
relevance 0../src/torrent.cpp:9758go 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
go through the pieces we have and count the total number
+
relevance 0../src/torrent.cpp:9768go 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
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
../src/torrent.cpp:9758
			}
+it num_interested == 0, we need to pick a new piece
../src/torrent.cpp:9768
			}
 
 			rarest_pieces.clear();
 			rarest_rarity = pp.peer_count;
@@ -4938,8 +4938,8 @@ it num_interested == 0, we need to pick a new piece
../src/torrent.cpp:9
 		if (num_cache_pieces > m_torrent_file->num_pieces())
 			num_cache_pieces = m_torrent_file->num_pieces();
 
-
relevance 0../src/torrent.cpp:10404instead of resorting the whole list, insert the peers directly into the right place
instead of resorting the whole list, insert the peers
-directly into the right place
../src/torrent.cpp:10404
				printf("timed out [average-piece-time: %d ms ]\n"
+
relevance 0../src/torrent.cpp:10414instead of resorting the whole list, insert the peers directly into the right place
instead of resorting the whole list, insert the peers
+directly into the right place
../src/torrent.cpp:10414
				printf("timed out [average-piece-time: %d ms ]\n"
 					, m_average_piece_time);
 #endif
 			}
@@ -6055,7 +6055,7 @@ m_sock.bind(endpoint, ec);
../include/libtorrent/proxy_base.hpp:166

 		m_sock.close(ec);
 		m_resolver.cancel();
 	}
-
relevance 0../include/libtorrent/session.hpp:856add get_peer_class_type_filter() as well
add get_peer_class_type_filter() as well
../include/libtorrent/session.hpp:856
		// 
+
relevance 0../include/libtorrent/session.hpp:857add get_peer_class_type_filter() as well
add get_peer_class_type_filter() as well
../include/libtorrent/session.hpp:857
		// 
 		// The ``peer_class`` argument cannot be greater than 31. The bitmasks
 		// representing peer classes in the ``peer_class_filter`` are 32 bits.
 		//