Table of contents
typedef storage_interface* (&storage_constructor_type)(
- file_storage const&, file_storage const*, fs::path const&, file_pool&);
+ file_storage const&, file_storage const*, fs::path const&, file_pool&
+ , std::vector<boost::uint8_t> const&);
struct add_torrent_params
{
add_torrent_params(storage_constructor_type s);
+ int version;
boost::intrusive_ptr<torrent_info> ti;
char const* tracker_url;
sha1_hash info_hash;
@@ -670,6 +673,7 @@ struct add_torrent_params
bool seed_mode;
bool override_resume_data;
bool upload_mode;
+ std::vector<boost::uint8_t> const* file_priorities;
};
torrent_handle add_torrent(add_torrent_params const& params);
@@ -760,6 +764,10 @@ which means it will not make any piece requests. This state is typically entered
on disk I/O errors, and if the torrent is also auto managed, it will be taken out
of this state periodically. This mode can be used to avoid race conditions when
adjusting priorities of pieces before allowing the torrent to start downloading.
+file_priorities can be set to control the initial file priorities when adding
+a torrent. The semantics are the same as for torrent_handle::prioritize_files().
+version is filled in by the constructor and should be left untouched. It
+is used for forward binary compatibility.
std::string const& name() const; std::string const& comment() const; -boost::optional<boost::posix_time::ptime> creation_date() const; +std::string const& creator() const; +boost::optional<time_t> creation_date() const;
name() returns the name of the torrent.
comment() returns the comment associated with the torrent. If there's no comment, -it will return an empty string. creation_date() returns a boost::posix_time::ptime -object, representing the time when this torrent file was created. If there's no time stamp -in the torrent file, this will return a date of January 1:st 1970.
+it will return an empty string. creation_date() returns the creation date of +the torrent as time_t (posix time). If there's no time stamp in the torrent file, +the optional object will be uninitialized.Both the name and the comment is UTF-8 encoded strings.
creator() returns the creator string in the torrent. If there is no creator string it will return an empty string.
@@ -2359,7 +2367,7 @@ Once the operation completes, the storage_moved_failed_alert is generated instead, containing the error message.@@ -2541,7 +2549,7 @@ void set_peer_download_limit(asio::ip::tcp::endpoint ip, int limit) const;Works like set_upload_limit and set_download_limit respectively, but controls individual peer instead of the whole torrent.
@@ -2783,8 +2791,10 @@ void use_interface(char const* net_interface) const;
use_interface() sets the network interface this torrent will use when it opens outgoing connections. By default, it uses the same interface as the session uses to listen on. The -parameter must be a string containing an ip-address (either an IPv4 or IPv6 address). If -the string does not conform to this format and exception is thrown.
+parameter must be a string containing one or more, comma separated, ip-address (either an +IPv4 or IPv6 address). When specifying multiple interfaces, the torrent will round-robin +which interface to use for each outgoing conneciton. This is useful for clients that are +multi-homed.info_hash() returns the info-hash for the torrent.
@@ -2807,7 +2817,7 @@ int max_uploads() const; torrent. If you set this to -1, there will be no limit.max_uploads() returns the current settings.
@@ -2928,7 +2938,7 @@ torrent was first loaded or since the last time the resume data was saved. When saving resume data periodically, it makes sense to skip any torrent which hasn't downloaded anything since the last time.
@@ -3169,6 +3179,9 @@ struct torrent_status time_t added_time; time_t completed_time; time_t last_seen_complete; + + int time_since_upload; + int time_since_download; };progress is a value in the range [0, 1], that represents the progress of the @@ -3368,6 +3381,9 @@ take it out of the upload mode by calling last_seen_complete is the time when we, or one of our peers, last saw a complete copy of this torrent.
+time_since_upload and time_since_download are the number of +seconds since any peer last uploaded from this torrent and the last +time a downloaded piece passed the hash check, respectively.
The flags attribute tells you in which state the peer is. It is set to @@ -3700,6 +3718,9 @@ reset to 0 on reconnect.
floating point operations are diabled, instead use progress_ppm.progress_ppm indicates the download progress of the peer in the range [0, 1000000] (parts per million).
+local_endpoint is the IP and port pair the socket is bound to locally. i.e. the IP +address of the interface it's going out over. This may be useful for multi-homed +clients with multiple interfaces to the internet.
version is automatically set to the libtorrent version you're using +in order to be forward binary compatible. This field should not be changed.
user_agent this is the client identification to the tracker. The recommended format of this string is: "ClientName/ClientVersion libtorrent/libtorrentVersion". @@ -4537,6 +4561,7 @@ struct proxy_settings }; proxy_type type; + bool proxy_hostnames; }; @@ -4565,6 +4590,9 @@ and password will not be used. user authorization. The username and password will be sent to the proxy. +
proxy_hostnames defaults to true. It means that hostnames should be +attempted to be resolved through the proxy instead of using the local DNS +service. This is only supported by SOCKS5 and HTTP.
@@ -5604,6 +5632,17 @@ struct block_finished_alert: peer_alert };
This alert is generated when we receive a local service discovery message from a peer +for a torrent we're currently participating in.
+
+struct lsd_peer_alert: peer_alert
+{
+ // ...
+};
+
+This is posted whenever an individual file completes its download. i.e. @@ -5700,6 +5739,60 @@ struct performance_alert: torrent_alert performance_warning_t warning_code; }; +
We're stalled on the disk. We want to write to the socket, and we can write +but our send buffer is empty, waiting to be refilled from the disk. +This either means the disk is slower than the network connection +or that our send buffer watermark is too small, because we can +send it all before the disk gets back to us. +The number of bytes that we keep outstanding, requested from the disk, is calculated +as follows:
++min(512, max(upload_rate * send_buffer_watermark_factor, send_buffer_watermark)) ++
If you receive this alert, you migth want to either increase your send_buffer_watermark +or send_buffer_watermark_factor.
+@@ -6965,7 +7058,7 @@ should be moved to slot1This is only used in compact mode.Returning true indicates an error occurred.
diff --git a/docs/manual.rst b/docs/manual.rst index 1199fd065..690d9b3ad 100644 --- a/docs/manual.rst +++ b/docs/manual.rst @@ -6021,6 +6021,63 @@ upload or download rate performance. performance_warning_t warning_code; }; +outstanding_disk_buffer_limit_reached + This warning means that the number of bytes queued to be written to disk + exceeds the max disk byte queue setting (``session_settings::max_queued_disk_bytes``). + This might restrict the download rate, by not queuing up enough write jobs + to the disk I/O thread. When this alert is posted, peer connections are + temporarily stopped from downloading, until the queued disk bytes have fallen + below the limit again. Unless your ``max_queued_disk_bytes`` setting is already + high, you might want to increase it to get better performance. + +outstanding_request_limit_reached + This is posted when libtorrent would like to send more requests to a peer, + but it's limited by ``session_settings::max_out_request_queue``. The queue length + libtorrent is trying to achieve is determined by the download rate and the + assumed round-trip-time (``session_settings::request_queue_time``). The assumed + rount-trip-time is not limited to just the network RTT, but also the remote disk + access time and message handling time. It defaults to 3 seconds. The target number + of outstanding requests is set to fill the bandwidth-delay product (assumed RTT + times download rate divided by number of bytes per request). When this alert + is posted, there is a risk that the number of outstanding requests is too low + and limits the download rate. You might want to increase the ``max_out_request_queue`` + setting. + +upload_limit_too_low + This warning is posted when the amount of TCP/IP overhead is greater than the + upload rate limit. When this happens, the TCP/IP overhead is caused by a much + faster download rate, triggering TCP ACK packets. These packets eat into the + rate limit specified to libtorrent. When the overhead traffic is greater than + the rate limit, libtorrent will not be able to send any actual payload, such + as piece requests. This means the download rate will suffer, and new requests + can be sent again. There will be an equilibrium where the download rate, on + average, is about 20 times the upload rate limit. If you want to maximize the + download rate, increase the upload rate limit above 5% of your download capacity. + +download_limit_too_low + This is the same warning as ``upload_limit_too_low`` but referring to the download + limit instead of upload. This suggests that your download rate limit is mcuh lower + than your upload capacity. Your upload rate will suffer. To maximize upload rate, + make sure your download rate limit is above 5% of your upload capacity. + +send_buffer_watermark_too_low + We're stalled on the disk. We want to write to the socket, and we can write + but our send buffer is empty, waiting to be refilled from the disk. + This either means the disk is slower than the network connection + or that our send buffer watermark is too small, because we can + send it all before the disk gets back to us. + The number of bytes that we keep outstanding, requested from the disk, is calculated + as follows:: + + min(512, max(upload_rate * send_buffer_watermark_factor, send_buffer_watermark)) + + If you receive this alert, you migth want to either increase your ``send_buffer_watermark`` + or ``send_buffer_watermark_factor``. + +too_many_optimistic_unchoke_slots + If the half (or more) of all upload slots are set as optimistic unchoke slots, this + warning is issued. You probably want more regular (rate based) unchoke slots. + state_changed_alert -------------------