Extensions
diff --git a/docs/manual.html b/docs/manual.html index 7a623d2f7..ec7eceb74 100644 --- a/docs/manual.html +++ b/docs/manual.html @@ -227,74 +227,75 @@Whenever a torrent encounters a fatal error, it will be stopped, and the -session_status::error will describe the error that caused it. If a torrent +torrent_status::error will describe the error that caused it. If a torrent is auto managed, it is scraped periodically and paused or resumed based on the number of downloaders per seed. This will effectively seed torrents that are in the greatest need of seeds.
@@ -740,7 +741,8 @@ the tracker that we've stopped participating in the swarm. The optional second a options can be used to delete all the files downloaded by this torrent. To do this, pass in the value session::delete_files. The removal of the torrent is asyncronous, there is no guarantee that adding the same torrent immediately after it was removed will not throw -a libtorrent_exception exception. +a libtorrent_exception exception. Once the torrent is deleted, a torrent_deleted_alert +is posted.user_agent this is the client identification to the tracker. @@ -3824,6 +3841,15 @@ pieces in any torrent are picked at random, the following pieces are picked in rarest first order.
allowed_fast_set_size is the number of pieces we allow peers to download from us without being unchoked.
+suggest_mode controls whether or not libtorrent will send out suggest +messages to create a bias of its peers to request certain pieces. The modes +are:
+max_queued_disk_bytes is the number maximum number of bytes, to be written to disk, that can wait in the disk I/O thread queue. This queue is only for waiting for the disk I/O thread to receive the job and either @@ -3882,6 +3908,19 @@ saves memory at the expense of more heap allocations. It must be at least 1.
in the write cache, to when it's forcefully flushed to disk. Default is 60 second.use_read_cache, is set to true (default), the disk cache is also used to cache pieces read from disk. Blocks for writing pieces takes presedence.
+explicit_read_cache defaults to 0. If set to something greater than 0, the +disk read cache will not be evicted by cache misses and will explicitly be +controlled based on the rarity of pieces. Rare pieces are more likely to be +cached. This would typically be used together with suggest_mode set to +suggest_read_cache. The value is the number of pieces to keep in the read +cache. If the actual read cache can't fit as many, it will essentially be clamped.
+explicit_cache_interval is the number of seconds in between each refresh of +a part of the explicit read cache. Torrents take turns in refreshing and this +is the time in between each torrent refresh. Refreshing a torrent's explicit +read cache means scanning all pieces and picking a random set of the rarest ones. +There is an affinity to pick pieces that are already in the cache, so that +subsequent refreshes only swaps in pieces that are rarer than whatever is in +the cache at the time.
disk_io_no_buffer defaults to true. When set to true, files are preferred to be opened in unbuffered mode. This helps the operating system from growing its file cache indefinitely. Currently only files whose offset in the torrent @@ -4054,6 +4093,47 @@ bittorrent clients.
max_suggest_pieces is the max number of suggested piece indices received from a peer that's remembered. If a peer floods suggest messages, this limit prevents libtorrent from using too much RAM. It defaults to 10.
+If drop_skipped_requests is set to true (it defaults to false), piece +requests that have been skipped enough times when piece messages +are received, will be considered lost. Requests are considered skipped +when the returned piece messages are re-ordered compared to the order +of the requests. This was an attempt to get out of dead-locks caused by +BitComet peers silently ignoring some requests. It may cause problems +at high rates, and high level of reordering in the uploading peer, that's +why it's disabled by default.
+low_prio_disk determines if the disk I/O should use a normal +or low priority policy. This defaults to true, which means that +it's low priority by default. Other processes doing disk I/O will +normally take priority in this mode. This is meant to improve the +overall responsiveness of the system while downloading in the +background. For high-performance server setups, this might not +be desirable.
+local_service_announce_interval is the time between local +network announces for a torrent. By default, when local service +discovery is enabled a torrent announces itself every 5 minutes. +This interval is specified in seconds.
+volatile_read_cache, if this is set to true, read cache blocks +that are hit by peer read requests are removed from the disk cache +to free up more space. This is useful if you don't expect the disk +cache to create any cache hits from other peers than the one who +triggered the cache line to be read into the cache in the first place.
+guided_read_cache enables the disk cache to adjust the size +of a cache line generated by peers to depend on the upload rate +you are sending to that peer. The intention is to optimize the RAM +usage of the cache, to read ahead further for peers that you're +sending faster to.
+default_min_cache_age is the minimum number of seconds any read +cache line is kept in the cache. This defaults to one second but +may be greater if guided_read_cache is enabled. Having a lower +bound on the time a cache line stays in the cache is an attempt +to avoid swapping the same pieces in and out of the cache in case +there is a shortage of spare cache space.
+udp_tracker_token_expiry is the number of seconds libtorrent +will keep UDP tracker connection tokens around for. This is specified +to be 60 seconds, and defaults to that. The higher this value is, the +fewer packets have to be sent to the UDP tracker. In order for higher +values to work, the tracker needs to be configured to match the +expiration time for tokens.
This alert is generated when a request to delete the files of a torrent complete.
+The info_hash is the info-hash of the torrent that was just deleted. Most of +the time the torrent_handle in the torrent_alert will be invalid by the time +this alert arrives, since the torrent is being deleted. The info_hash member +is hence the main way of identifying which torrent just completed the delete.
+This alert is posted in the storage_notification category, and that bit +needs to be set in the alert mask.
+
+struct torrent_deleted_alert: torrent_alert
+{
+ // ...
+ sha1_hash info_hash;
+};
+
+This alert is generated when a torrent switches from being a downloader to a seed. @@ -5279,7 +5376,8 @@ struct performance_alert: torrent_alert outstanding_request_limit_reached, upload_limit_too_low, download_limit_too_low, - send_buffer_watermark_too_low + send_buffer_watermark_too_low, + too_many_optimistic_unchoke_slots }; performance_warning_t warning_code; @@ -6819,7 +6917,7 @@ idle in a select() ca that will send and receive data on all connections.
hrktorrent
hrktorrent hrktorrent is a light console torrent client written in C++.
DelCo
-DelCo is a research project at tempere university of technology, finland.
+DelCo is a research project at Tampere university of technology, finland.
FireANT
FireANT is a video blog available for Windows and Mac OSX.
diff --git a/docs/tuning.html b/docs/tuning.html index 3366a9a8c..88d1ddc3d 100644 --- a/docs/tuning.html +++ b/docs/tuning.html @@ -246,6 +246,39 @@ to true.In order to increase the possibility of read cache hits, set the session_settings::cache_expiry to a large number. This won't degrade anything as long as the client is only seeding, and not downloading any torrents.
+In order to increase the disk cache hit rate, you can enable suggest messages based on +what's in the read cache. To do this, set session_settings::suggest_mode to +session_settings::suggest_read_cache. This will send suggest messages to peers +for the most recently used pieces in the read cache. This is especially useful if you +also enable explicit read cache, by settings session_settings::explicit_read_cache +to the number of pieces to keep in the cache. The explicit read cache will make the +disk read cache stick, and not be evicted by cache misses. The explicit read cache +will automatically pull in the rarest pieces in the read cache.
+Assuming that you seed much more data than you can keep in the cache, to a large +numbers of peers (so that the read cache wouldn't be useful anyway), this may be a +good idea.
+When peers first connect, libtorrent will send them a number of allow-fast messages, +which lets the peers download certain pieces even when they are choked, since peers +are choked by default, this often triggers immediate requests for those pieces. In the +case of using explicit read cache and suggesting those pieces, allowing fast pieces +should be disabled, to not systematically trigger requests for pieces that are not cached +for all peers. You can turn off allow-fast by settings session_settings::allowed_fast_set_size +to 0.
+As an alternative to the explicit cache and suggest messages, there's a guided cache +mode. This means the size of the read cache line that's stored in the cache is determined +based on the upload rate to the peer that triggered the read operation. The idea being +that slow peers don't use up a disproportional amount of space in the cache. This +is enabled through session_settings::guided_read_cache.
+In cases where the assumption is that the cache is only used as a read-ahead, and that no +other peer will ever request the same block while it's still in the cache, the read +cache can be set to be volatile. This means that every block that is requested out of +the read cache is removed immediately. This saves a significant amount of cache space +which can be used as read-ahead for other peers. This mode should never be combined +with either explicit_read_cache or suggest_read_cache, since those uses opposite +strategies for the read cache. You don't want to on one hand attract peers to request +the same pieces, and on the other hand assume that they won't request the same pieces +and drop them when the first peer requests it. To enable volatile read cache, set +session_settings::volatile_read_cache to true.