update queuing documentation and regenerate html

docs/manual.rst

@@ -189,6 +189,24 @@ well. If there are more non-auto managed torrents being downloaded than the
 settings_pack::active_downloads setting, any auto managed torrents will be queued until
 torrents are removed so that the number drops below the limit.
 
+In addition to the downloading and seeding limits, there are limits on *actions*
+torrents perform. The downloading and seeding limits control whether peers are
+allowed at all, and if peers are not allowed, torrents are stopped and don't do
+anything. If peers are allowed, torrents may:
+
+1. announce to trackers
+2. announce to the DHT
+3. announce to local peer discovery (local service discovery)
+
+Each of those actions are associated with a cost and hence may need a seprarate
+limit. These limits are controlled by settings_pack::active_tracker_limit,
+settings_pack::active_dht_limit and settings_pack::active_lsd_limit
+respectively.
+
+A client that is not concerned about the separate costs of these actions should
+set all 3 of these limits to the same value as settings_pack::active_limit (i.e.
+the max limit of any active torrent).
+
 At a regular interval, torrents are checked if there needs to be any
 re-ordering of which torrents are active and which are queued. This interval
 can be controlled via settings_pack::auto_manage_interval.

docs/python_binding.html

@@ -102,7 +102,7 @@ directory and invoke <tt class="docutils literal">bjam</tt> with the apropriate
 build variants, see <a class="reference external" href="building.html#step-3-building-libtorrent">libtorrent build options</a>.</p>
 <p>For example:</p>
 <pre class="literal-block">
-$ bjam dht-support=on boost=source release link=static
+$ bjam dht-support=on link=static
 </pre>
 <p>On Mac OS X, this will produce the following python module:</p>
 <pre class="literal-block">

docs/settings.rst

@@ -866,27 +866,6 @@ tracker or not. Defaults to on. Turning it off also excludes web
 seed traffic from other stats and download rate reporting via the
 libtorrent API.
 
-.. _utp_dynamic_sock_buf:
-
-.. raw:: html
-
-	<a name="utp_dynamic_sock_buf"></a>
-
-+----------------------+------+---------+
-| name                 | type | default |
-+======================+======+=========+
-| utp_dynamic_sock_buf | bool | true    |
-+----------------------+------+---------+
-
-controls if the uTP socket manager is allowed to increase the
-socket buffer if a network interface with a large MTU is used (such
-as loopback or ethernet jumbo frames). This defaults to true and
-might improve uTP throughput. For RAM constrained systems,
-disabling this typically saves around 30kB in user space and
-probably around 400kB in kernel socket buffers (it adjusts the send
-and receive buffer size on the kernel socket, both for IPv4 and
-IPv6).
-
 .. _announce_double_nat:
 
 .. raw:: html
@@ -1334,6 +1313,21 @@ pieces (and seeds) are downloaded sequentially. This is more
 efficient for the disk I/O. With many seeds, the download order is
 unlikely to matter anyway
 
+.. _proxy_tracker_connections:
+
+.. raw:: html
+
+	<a name="proxy_tracker_connections"></a>
+
++---------------------------+------+---------+
+| name                      | type | default |
++===========================+======+=========+
+| proxy_tracker_connections | bool | true    |
++---------------------------+------+---------+
+
+if true, trackerconnections are made over the configured proxy, if
+any.
+
 .. _tracker_completion_timeout:
 
 .. raw:: html
@@ -3163,6 +3157,7 @@ control the settings for incoming and outgoing connections
 respectively. see enc_policy enum for the available options.
 Keep in mind that protocol encryption degrades performance in
 several respects:
+
 1. It prevents "zero copy" disk buffers being sent to peers, since
    each peer needs to mutate the data (i.e. encrypt it) the data
    must be copied per peer connection rather than sending the same
@@ -3171,7 +3166,7 @@ several respects:
    protocol. The highest cost is the Diffie Hellman exchange on
    connection setup.
 3. The encryption handshake adds several round-trips to the
-connection setup, and delays transferring data.
+   connection setup, and delays transferring data.
 
 .. _allowed_enc_level:
 

include/libtorrent/session_handle.hpp

@@ -273,7 +273,7 @@ namespace libtorrent
 		//
 		// The signature of the function to pass in is::
 		//
-		// void fun(sha1_hash const& info_hash, std::vector<char>& buf, error_code& ec);
+		// 	void fun(sha1_hash const& info_hash, std::vector<char>& buf, error_code& ec);
 		void set_load_function(user_load_function_t fun);
 
 #ifndef TORRENT_NO_DEPRECATE

include/libtorrent/settings_pack.hpp

@@ -1469,6 +1469,7 @@ namespace libtorrent
 			// respectively. see enc_policy enum for the available options.
 			// Keep in mind that protocol encryption degrades performance in
 			// several respects:
+			// 
 			// 1. It prevents "zero copy" disk buffers being sent to peers, since
 			//    each peer needs to mutate the data (i.e. encrypt it) the data
 			//    must be copied per peer connection rather than sending the same
@@ -1477,7 +1478,7 @@ namespace libtorrent
 			//    protocol. The highest cost is the Diffie Hellman exchange on
 			//    connection setup.
 			// 3. The encryption handshake adds several round-trips to the
-			// connection setup, and delays transferring data.
+			//    connection setup, and delays transferring data.
 			out_enc_policy,
 			in_enc_policy,
 
@@ -1533,7 +1534,7 @@ namespace libtorrent
 			fastest_upload,
 			anti_leech
 		};
- 
+
 		enum io_buffer_mode_t
 		{
 			enable_os_cache = 0,