This setting will only have an affect on windows. +Other platforms are expected to support UTF-8.
+The variant feature is implicit, which means you don't need to specify diff --git a/docs/manual.html b/docs/manual.html index ef2cb3457..d660f474c 100644 --- a/docs/manual.html +++ b/docs/manual.html @@ -41,131 +41,135 @@
+++void set_peer_proxy(proxy_settings const& s); +void set_web_seed_proxy(proxy_settings const& s); +void set_tracker_proxy(proxy_settings const& s); +void set_dht_proxy(proxy_settings const& s); ++
The set_dht_proxy is not available when DHT is disabled. These functions +sets the proxy settings for different kinds of connections, bittorrent peers, +web seeds, trackers and the DHT traffic.
+set_peer_proxy affects regular bittorrent peers. set_web_seed_proxy +affects only web seeds. see HTTP seeding.
+set_tracker_proxy only affects HTTP tracker connections (UDP tracker +connections are affected if the given proxy supports UDP, e.g. SOCKS5).
+set_dht_proxy affects the DHT messages. Since they are sent over UDP, +it only has any effect if the proxy supports UDP.
+For more information on what settings are available for proxies, see +proxy_settings.
++++proxy_settings const& peer_proxy() const; +proxy_settings const& web_seed_proxy() const; +proxy_settings const& tracker_proxy() const; +proxy_settings const& dht_proxy() const; ++
These functions returns references to their respective current settings.
+The dht_proxy is not available when DHT is disabled.
+@@ -1334,6 +1381,7 @@ By default all pieces have priority 1. That means that the random rarest first algorithm is effectively active for all pieces. You may however change the priority of individual pieces. There are 8 different priority levels: ++
- piece is not downloaded at all
- normal priority. Download order is dependent on availability
@@ -1347,6 +1395,7 @@ lower availability- maximum priority, availability is disregarded, the piece is preferred over any other piece with lower priority
The exact definitions of these priorities are implementation details, and subject to change. The interface guarantees that higher number means higher priority, and that 0 means do not download.
@@ -1644,6 +1693,9 @@ not be ready to write resume data.Note that by the time this function returns, the resume data may already be invalid if the torrent is still downloading! The recommended practice is to first pause the torrent, then generate the fast resume data, and then close it down.
+It is still a good idea to save resume data periodically during download as well as when +closing down. In full allocation mode the reume data is never invalidated by subsequent +writes to the files, since pieces won't move around.
piece_index is the index of the piece in question. blocks_in_piece is the @@ -1692,6 +1746,12 @@ peer the piece was requested from. If a piece hasn't been requested (the bit in or not. And the num_downloads array says how many times that block has been downloaded. When a piece fails a hash verification, single blocks may be re-downloaded to see if the hash test may pass then.
+piece_state is set to either fast, medium, slow or none. It tells which +download rate category the peers downloading this piece falls into. none means that no +peer is currently downloading any part of the piece. Peers prefer picking pieces from +the same category as themselves. The reason for this is to keep the number of partially +downloaded pieces down. Pieces set to none can be converted into any of fast, +medium or slow as soon as a peer want to download from it.
proxy_ip may be a hostname or ip to a http proxy to use. If this is -an empty string, no http proxy will be used.
-proxy_port is the port on which the http proxy listens. If proxy_ip -is empty, this will be ignored.
-proxy_login should be the login username for the http proxy, if this -empty, the http proxy will be tried to be used without authentication.
-proxy_password the password string for the http proxy.
user_agent this is the client identification to the tracker. The recommended format of this string is: "ClientName/ClientVersion libtorrent/libtorrentVersion". @@ -2219,6 +2268,59 @@ all trackers in its tracker list has failed. Either by an explicit error message or a time out.
The proxy_settings structs contains the information needed to +direct certain traffic to a proxy.
+
+
+struct TORRENT_EXPORT proxy_settings
+{
+ proxy_settings();
+
+ std::string hostname;
+ int port;
+
+ std::string username;
+ std::string password;
+
+ enum proxy_type
+ {
+ none,
+ socks5,
+ socks5_pw,
+ http,
+ http_pw
+ };
+
+ proxy_type type;
+};
+
+
+hostname is the name or IP of the proxy server. port is the +port number the proxy listens to. If required, username and password +can be set to authenticate with the proxy.
+The type tells libtorrent what kind of proxy server it is. The following +options are available:
++++
+- none - This is the default, no proxy server is used, all other fields +are ignored.
+- socks5 - The server is assumed to be a SOCKS5 server (RFC 1928) that +does not require any authentication. The username and password are ignored.
+- socks5_pw - The server is assumed to be a SOCKS5 server that supports +plain text username and password authentication (RFC 1929). The username +and password specified may be sent to the proxy if it requires.
+- http - The server is assumed to be an HTTP proxy. If the transport used +for the connection is non-HTTP, the server is assumed to support the +CONNECT method. i.e. for web seeds and HTTP trackers, a plain proxy will +suffice. The proxy is assumed to not require authorization. The username +and password will not be used.
+- http_pw - The server is assumed to be an HTTP proxy that requires +user authorization. The username and password will be sent to the proxy.
+
The ip_filter class is a set of rules that uniquely categorizes all ip addresses as allowed or disallowed. The default constructor creates @@ -2484,6 +2586,20 @@ entry e = bdecode(buf, buf + data_size);
If bdecode() encounters invalid encoded data in the range given to it it will throw invalid_encoding.
+++bool supports_sparse_files(boost::filesystem::path const&); ++
The path is expected to be the path to the directory where you will want to +store sparse files. The return value is true if the file system supports +sparse files or if it supports automatic zero filling of files. The main +characteristics that is tested by this function is not the storage aspects +of sparse files, but rather the support for seeking passed end of file and +write data there, with expected behavior.
+
- The traditional full allocation mode, where the entire files are filled up with -zeros before anything is downloaded.
+zeros before anything is downloaded. libtorrent will look for sparse files support +in the filesystem that is used for storage, and use sparse files or file system +zero fill support if present. This means that on NTFS, full allocation mode will +only allocate storage for the downloaded pieces.
The allocation mode is selected when a torrent is started. It is passed as a boolean argument to session::add_torrent() (see add_torrent()). These two modes have different drawbacks and benefits.
+The decision to use full allocation or compact allocation typically depends on whether +any files are filtered and if the filesystem supports sparse files.
+To know if the filesystem supports sparse files (and to know if libtorrent believes the +filesystem supports sparse files), see supports_sparse_files().
When a torrent is started in full allocation mode, the checker thread (see threads) will make sure that the entire storage is allocated, and fill any gaps with zeros. +This will be skipped if the filesystem supports sparse files or automatic zero filling. It will of course still check for existing pieces and fast resume data. The main drawbacks of this mode are:
-
@@ -3173,7 +3306,11 @@ and may slow down a download considerably.- It will take longer to start the torrent, since it will need to fill the files -with zeros. This delay is linearly dependent on the size of the download.
-- The download will occupy unnecessary disk space between download sessions.
+- It may take longer to start the torrent, since it will need to fill the files +with zeros on some systems. This delay is linearly dependent on the size of +the download.
+- The download may occupy unnecessary disk space between download sessions. In case +sparse files are not supported.
- Disk caches usually perform extremely poorly with random access to large files and may slow down a download considerably.
- Downloaded pieces are written directly to their final place in the files and the total number of disk operations will be fewer and may also play nicer to filesystems' file allocation, and reduce fragmentation.
-- No risk of a download failing because of a full disk during download.
+- No risk of a download failing because of a full disk during download. Unless +sparse files are being used.
+- The fast resume data will be more likely to be usable, regardless of crashes or +out of date data, since pieces won't move around.
+- Can be used with the filter files feature.
The benefits though, are:
@@ -3196,6 +3334,7 @@ download has all its pieces in the correct place). So, the main drawbacks are:The download will not use unnecessary disk space.The algorithm that is used when allocating pieces and slots isn't very complicated.
diff --git a/src/peer_connection.cpp b/src/peer_connection.cpp
index b72b57759..f239a5fea 100755
--- a/src/peer_connection.cpp
+++ b/src/peer_connection.cpp
@@ -1334,7 +1334,7 @@ namespace libtorrent
peer_speed_t speed = peer_speed();
if (speed == fast) state = piece_picker::fast;
else if (speed == medium) state = piece_picker::medium;
- else if (speed == slow) state = piece_picker::slow;
+ else state = piece_picker::slow;
t->picker().mark_as_downloading(block, m_remote, state);
@@ -2425,8 +2425,8 @@ namespace libtorrent
shared_ptr