From 6a87600094ef32d5a0038b13a5f510dff78ca8d1 Mon Sep 17 00:00:00 2001 From: Arvid Norberg Date: Fri, 24 Oct 2014 00:19:44 +0000 Subject: [PATCH] regenerated html --- docs/building.html | 7 - docs/examples.html | 2 +- docs/index.html | 2 +- docs/reference-Session.html | 4 +- docs/settings.rst | 5 - docs/todo.html | 865 +++++++++++++++++------------------- docs/troubleshooting.html | 2 +- 7 files changed, 422 insertions(+), 465 deletions(-) diff --git a/docs/building.html b/docs/building.html index 9a513b1ff..21cbded60 100644 --- a/docs/building.html +++ b/docs/building.html @@ -676,13 +676,6 @@ support for various UPnP routers. which later can parsed and graphed using parse_disk_log.py. -TORRENT_STATS -This will generate a log with transfer rates, -downloading torrents, seeding torrents, peers, -connecting peers and disk buffers in use. The -log can be parsed and graphed with -parse_session_stats.py. - UNICODE If building on windows this will make sure the UTF-8 strings in pathnames are converted into diff --git a/docs/examples.html b/docs/examples.html index baa2a700a..a9e64e0e4 100644 --- a/docs/examples.html +++ b/docs/examples.html @@ -41,7 +41,7 @@ Author: Arvid Norberg, arvid@libtorrent.org Version: -1.0.3 +1.1.0
diff --git a/docs/index.html b/docs/index.html index 7ce43bdb1..87b2bacfa 100644 --- a/docs/index.html +++ b/docs/index.html @@ -41,7 +41,7 @@ Author: Arvid Norberg, arvid@libtorrent.org Version: -1.0.3 +1.1.0
    diff --git a/docs/reference-Session.html b/docs/reference-Session.html index ea68ab14c..9215d2a37 100644 --- a/docs/reference-Session.html +++ b/docs/reference-Session.html @@ -41,7 +41,7 @@ Author: Arvid Norberg, arvid@libtorrent.org Version: -1.0.0 +1.1.0
    @@ -1079,7 +1079,7 @@ void dht_put_item (boost::array<char, 32> key , boost::uint64_t&, std::string const&)> cb , std::string salt = std::string()); -

    store an immutable item. The key is the public key the blob is +

    store a mutable item. The key is the public key the blob is to be stored under. The optional salt argument is a string that is to be mixed in with the key when determining where in the DHT the value is to be stored. The callback function is called from within diff --git a/docs/settings.rst b/docs/settings.rst index 9a8de0a76..ee3d911bb 100644 --- a/docs/settings.rst +++ b/docs/settings.rst @@ -1848,11 +1848,6 @@ The options for choking algorithms are: * ``fixed_slots_choker`` is the traditional choker with a fixed number of unchoke slots (as specified by ``session::set_max_uploads()``). -* ``auto_expand_choker`` opens at least the number of slots as specified by - ``session::set_max_uploads()`` but opens up more slots if the upload capacity - is not saturated. This unchoker will work just like the ``fixed_slots_choker`` - if there's no global upload rate limit set. - * ``rate_based_choker`` opens up unchoke slots based on the upload rate achieved to peers. The more slots that are opened, the marginal upload rate required to open up another slot increases. diff --git a/docs/todo.html b/docs/todo.html index f902df147..a68dd3a1c 100644 --- a/docs/todo.html +++ b/docs/todo.html @@ -22,10 +22,10 @@

    libtorrent todo-list

    0 urgent -20 important -28 relevant +18 important +29 relevant 8 feasible -134 notes +136 notes - +
    relevance 3../test/test_dht.cpp:436test obfuscated_get_peers
    relevance 3../src/peer_connection.cpp:1846we should probably use ses.m_allowed_upload_slots here instead to work with auto-unchoke logic
    relevance 3../src/peer_connection.cpp:1685we should probably use ses.m_allowed_upload_slots here instead to work with auto-unchoke logic
    relevance 3../src/peer_connection.cpp:3176since we throw away the queue entry once we issue the disk job, this may happen. Instead, we should keep the queue entry around, mark it as having been requested from disk and once the disk job comes back, discard it if it has been cancelled. Maybe even be able to cancel disk jobs?
    relevance 3../src/peer_connection.cpp:3015since we throw away the queue entry once we issue the disk job, this may happen. Instead, we should keep the queue entry around, mark it as having been requested from disk and once the disk job comes back, discard it if it has been cancelled. Maybe even be able to cancel disk jobs?
    relevance 3../src/peer_connection.cpp:4917instead of using settings_pack::request_timeout, use m_rtt.mean() + m_rtt.avg_deviation() * 2 or something like that. the configuration option could hopefully be removed
    relevance 3../src/peer_connection.cpp:4754instead of using settings_pack::request_timeout, use m_rtt.mean() + m_rtt.avg_deviation() * 2 or something like that. the configuration option could hopefully be removed
    relevance 3../src/resolver.cpp:39the first places to use this resolver is the http_connection/http_tracker_connection and udp_tracker_connection. make sure to prefer cache on shutdown
    relevance 3../src/session_impl.cpp:1574return the listen_socket_t instead of taking it as an out-parameter
    relevance 3../src/session_impl.cpp:4486it 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
    relevance 3../src/session_impl.cpp:4370it 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
    relevance 3../src/session_impl.cpp:5345deprecate this function. All of this functionality should be exposed as performance counters
    relevance 3../src/session_impl.cpp:5229deprecate this function. All of this functionality should be exposed as performance counters
    relevance 3../src/session_impl.cpp:5938If socket jobs could be higher level, to include RC4 encryption and decryption, we would offload the main thread even more
    relevance 3../src/session_impl.cpp:5819If socket jobs could be higher level, to include RC4 encryption and decryption, we would offload the main thread even more
    relevance 3../src/torrent.cpp:1083if any other peer has a busy request to this block, we need to cancel it too
    relevance 3../src/torrent.cpp:1083if any other peer has a busy request to this block, we need to cancel it too
    relevance 3../src/torrent.cpp:7685if peer is a really good peer, maybe we shouldn't disconnect it
    relevance 3../src/torrent.cpp:7682if peer is a really good peer, maybe we shouldn't disconnect it
    relevance 3../src/web_peer_connection.cpp:596just make this peer not have the pieces associated with the file we just requested. Only when it doesn't have any of the file do the following
    relevance 3../src/web_peer_connection.cpp:596just make this peer not have the pieces associated with the file we just requested. Only when it doesn't have any of the file do the following
    relevance 3../include/libtorrent/block_cache.hpp:209could this be a scoped_array instead? does cached_piece_entry really need to be copyable? cached_piece_entry does need to be copyable since it's part of a container, but it's possible it could be a raw pointer or boost::unique_ptr perhaps
    relevance 3../include/libtorrent/block_cache.hpp:209could this be a scoped_array instead? does cached_piece_entry really need to be copyable? cached_piece_entry does need to be copyable since it's part of a container, but it's possible it could be a raw pointer or boost::unique_ptr perhaps
    relevance 3../include/libtorrent/disk_io_thread.hpp:537turn these counters and gauges into session_stats counters (which also would need to be thread safe)
    relevance 3../include/libtorrent/disk_io_thread.hpp:537turn these counters and gauges into session_stats counters (which also would need to be thread safe)
    relevance 3../include/libtorrent/policy.hpp:104this class should be renamed peer_list
    relevance 3../include/libtorrent/policy.hpp:104this class should be renamed peer_list
    relevance 3../include/libtorrent/session.hpp:210could the fingerprint be a setting as well? And should the settings_pack be optional?
    relevance 3../include/libtorrent/session.hpp:210could the fingerprint be a setting as well? And should the settings_pack be optional?
    relevance 3../include/libtorrent/torrent_info.hpp:221this type should be different from the one used by torrent. It should not include internal state.
    relevance 3../include/libtorrent/torrent_info.hpp:221this type should be different from the one used by torrent. It should not include internal state.
    relevance 2../src/disk_io_thread.cpp:844should this be allocated on the stack?
    relevance 2../src/disk_io_thread.cpp:844should this be allocated on the stack?
    relevance 2../src/disk_io_thread.cpp:885we're not flushing the read cache at all?
    relevance 2../src/disk_io_thread.cpp:885we're not flushing the read cache at all?
    relevance 2../src/file.cpp:1491use vm_copy here, if available, and if buffers are aligned
    relevance 2../src/file.cpp:1491use vm_copy here, if available, and if buffers are aligned
    relevance 2../src/file.cpp:1502use vm_copy here, if available, and if buffers are aligned
    relevance 2../src/file.cpp:1502use vm_copy here, if available, and if buffers are aligned
    relevance 2../src/peer_connection.cpp:4839use a deadline_timer for timeouts. Don't rely on second_tick()! Hook this up to connect timeout as well. This would improve performance because of less work in second_tick(), and might let use remove ticking entirely eventually
    relevance 2../src/peer_connection.cpp:4676use a deadline_timer for timeouts. Don't rely on second_tick()! Hook this up to connect timeout as well. This would improve performance because of less work in second_tick(), and might let use remove ticking entirely eventually
    relevance 2../src/session_impl.cpp:227find a better place for this function
    relevance 2../src/session_impl.cpp:1833the udp socket(s) should be using the same generic mechanism and not be restricted to a single one we should open a one listen socket for each entry in the listen_interfaces list
    relevance 2../src/session_impl.cpp:1834the udp socket(s) should be using the same generic mechanism and not be restricted to a single one we should open a one listen socket for each entry in the listen_interfaces list
    relevance 2../src/session_impl.cpp:1933use bind_to_device in udp_socket
    relevance 2../src/session_impl.cpp:1931use bind_to_device in udp_socket
    relevance 2../src/session_impl.cpp:1958use bind_to_device in udp_socket
    relevance 2../src/session_impl.cpp:3392make 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
    relevance 2../src/torrent.cpp:701post alert
    relevance 2../src/torrent.cpp:701post alert
    relevance 2../src/torrent.cpp:4694abort lookups this torrent has made via the session host resolver interface
    relevance 2../src/torrent.cpp:4693abort lookups this torrent has made via the session host resolver interface
    relevance 2../src/web_peer_connection.cpp:655create a mapping of file-index to redirection URLs. Use that to form URLs instead. Support to reconnect to a new server without destructing this peer_connection
    relevance 2../src/kademlia/dos_blocker.cpp:75make these limits configurable
    relevance 2../src/kademlia/node.cpp:67make this configurable in dht_settings
    relevance 2../src/kademlia/node.cpp:804find_node should write directly to the response entry
    relevance 2../src/kademlia/node.cpp:804find_node should write directly to the response entry
    relevance 2../src/kademlia/node_id.cpp:133this could be optimized if SSE 4.2 is available. It could also be optimized given that we have a fixed length
    relevance 2../src/kademlia/node_id.cpp:133this could be optimized if SSE 4.2 is available. It could also be optimized given that we have a fixed length
    relevance 2../include/libtorrent/enum_net.hpp:137this could be done more efficiently by just looking up the interface with the given name, maybe even with if_nametoindex()
    relevance 2../include/libtorrent/enum_net.hpp:137this could be done more efficiently by just looking up the interface with the given name, maybe even with if_nametoindex()
    relevance 2../include/libtorrent/intrusive_ptr_base.hpp:44remove this class and transition over to using shared_ptr and make_shared instead
    relevance 2../include/libtorrent/intrusive_ptr_base.hpp:44remove this class and transition over to using shared_ptr and make_shared instead
    relevance 2../include/libtorrent/session_settings.hpp:55this type is only used internally now. move it to an internal header and make this type properly deprecated.
    relevance 2../include/libtorrent/proxy_base.hpp:257use the resolver interface that has a built-in cache
    relevance 2../include/libtorrent/session_settings.hpp:55this type is only used internally now. move it to an internal header and make this type properly deprecated.
    relevance 2../include/libtorrent/settings_pack.hpp:70add an API to query a settings_pack as well
    relevance 2../include/libtorrent/settings_pack.hpp:71maybe convert all bool types into int-types as well
    relevance 2../include/libtorrent/settings_pack.hpp:70add an API to query a settings_pack as well
    relevance 2../include/libtorrent/settings_pack.hpp:71maybe convert all bool types into int-types as well
    relevance 2../include/libtorrent/socks5_stream.hpp:129fix error messages to use custom error_code category
    relevance 2../include/libtorrent/socks5_stream.hpp:130add async_connect() that takes a hostname and port as well
    relevance 2../include/libtorrent/socks5_stream.hpp:129fix error messages to use custom error_code category
    relevance 2../include/libtorrent/socks5_stream.hpp:130add async_connect() that takes a hostname and port as well
    relevance 2../include/libtorrent/torrent_info.hpp:306there may be some opportunities to optimize the size if torrent_info. specifically to turn some std::string and std::vector into pointers
    relevance 2../include/libtorrent/torrent_info.hpp:306there may be some opportunities to optimize the size if torrent_info. specifically to turn some std::string and std::vector into pointers
    relevance 2../include/libtorrent/tracker_manager.hpp:270this class probably doesn't need to have virtual functions.
    relevance 2../include/libtorrent/tracker_manager.hpp:270this class probably doesn't need to have virtual functions.
    relevance 2../include/libtorrent/tracker_manager.hpp:367this should be unique_ptr in the future
    relevance 2../include/libtorrent/tracker_manager.hpp:367this should be unique_ptr in the future
    relevance 2../include/libtorrent/aux_/session_interface.hpp:107the IP voting mechanism should be factored out to its own class, not part of the session
    relevance 2../include/libtorrent/aux_/session_interface.hpp:107the IP voting mechanism should be factored out to its own class, not part of the session
    relevance 1../src/http_seed_connection.cpp:124in chunked encoding mode, this assert won't hold. the chunk headers should be subtracted from the receive_buffer_size
    relevance 1../src/http_seed_connection.cpp:124in chunked encoding mode, this assert won't hold. the chunk headers should be subtracted from the receive_buffer_size
    relevance 1../src/session_impl.cpp:5316report the proper address of the router as the source IP of this understanding of our external address, instead of the empty address
    relevance 1../src/session_impl.cpp:5200report the proper address of the router as the source IP of this understanding of our external address, instead of the empty address
    relevance 1../src/session_impl.cpp:6481we 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
    relevance 1../src/session_impl.cpp:6362we 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
    relevance 1../src/torrent.cpp:1142make this depend on the error and on the filesystem the files are being downloaded to. If the error is no_space_left_on_device and the filesystem doesn't support sparse files, only zero the priorities of the pieces that are at the tails of all files, leaving everything up to the highest written piece in each file
    relevance 1../src/torrent.cpp:1142make this depend on the error and on the filesystem the files are being downloaded to. If the error is no_space_left_on_device and the filesystem doesn't support sparse files, only zero the priorities of the pieces that are at the tails of all files, leaving everything up to the highest written piece in each file
    relevance 1../src/torrent.cpp:6837save the send_stats state instead of throwing them away it may pose an issue when downgrading though
    relevance 1../src/torrent.cpp:6834save the send_stats state instead of throwing them away it may pose an issue when downgrading though
    relevance 1../src/torrent.cpp:7933should 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
    relevance 1../src/torrent.cpp:7930should 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
    relevance 1../include/libtorrent/ip_voter.hpp:122instead, have one instance per possible subnet, global IPv4, global IPv6, loopback, 192.168.x.x, 10.x.x.x, etc.
    relevance 1../include/libtorrent/web_peer_connection.hpp:121if we make this be a disk_buffer_holder instead we would save a copy sometimes use allocate_disk_receive_buffer and release_disk_receive_buffer
    relevance 0../test/test_block_cache.cpp:472test try_evict_blocks
    relevance 0../test/test_block_cache.cpp:473test evicting volatile pieces, to see them be removed
    relevance 0../test/test_block_cache.cpp:474test evicting dirty pieces
    relevance 0../test/test_block_cache.cpp:475test free_piece
    relevance 0../test/test_block_cache.cpp:476test abort_dirty
    relevance 0../test/test_block_cache.cpp:477test unaligned reads
    relevance 0../test/test_block_cache.cpp:472test try_evict_blocks
    relevance 0../test/test_block_cache.cpp:473test evicting volatile pieces, to see them be removed
    relevance 0../test/test_block_cache.cpp:474test evicting dirty pieces
    relevance 0../test/test_block_cache.cpp:475test free_piece
    relevance 0../test/test_block_cache.cpp:476test abort_dirty
    relevance 0../test/test_block_cache.cpp:477test unaligned reads
    relevance 0../test/test_metadata_extension.cpp:87it would be nice to test reversing which session is making the connection as well
    relevance 0../test/test_metadata_extension.cpp:87it would be nice to test reversing which session is making the connection as well
    relevance 0../test/test_policy.cpp:419test applying a port_filter
    relevance 0../test/test_policy.cpp:420test erasing peers
    relevance 0../test/test_policy.cpp:421test using port and ip filter
    relevance 0../test/test_policy.cpp:422test incrementing failcount (and make sure we no longer consider the peer a connect canidate)
    relevance 0../test/test_policy.cpp:423test max peerlist size
    relevance 0../test/test_policy.cpp:424test logic for which connection to keep when receiving an incoming connection to the same peer as we just made an outgoing connection to
    relevance 0../test/test_policy.cpp:425test update_peer_port with allow_multiple_connections_per_ip
    relevance 0../test/test_policy.cpp:426test set_seed
    relevance 0../test/test_policy.cpp:427test has_peer
    relevance 0../test/test_policy.cpp:428test insert_peer with a full list
    relevance 0../test/test_policy.cpp:429test add i2p peers
    relevance 0../test/test_policy.cpp:430test allow_i2p_mixed
    relevance 0../test/test_policy.cpp:431test insert_peer failing
    relevance 0../test/test_policy.cpp:432test IPv6
    relevance 0../test/test_policy.cpp:433test connect_to_peer() failing
    relevance 0../test/test_policy.cpp:434test connection_closed
    relevance 0../test/test_policy.cpp:435test recalculate connect candidates
    relevance 0../test/test_policy.cpp:436add tests here
    relevance 0../test/test_policy.cpp:419test applying a port_filter
    relevance 0../test/test_policy.cpp:420test erasing peers
    relevance 0../test/test_policy.cpp:421test using port and ip filter
    relevance 0../test/test_policy.cpp:422test incrementing failcount (and make sure we no longer consider the peer a connect canidate)
    relevance 0../test/test_policy.cpp:423test max peerlist size
    relevance 0../test/test_policy.cpp:424test logic for which connection to keep when receiving an incoming connection to the same peer as we just made an outgoing connection to
    relevance 0../test/test_policy.cpp:425test update_peer_port with allow_multiple_connections_per_ip
    relevance 0../test/test_policy.cpp:426test set_seed
    relevance 0../test/test_policy.cpp:427test has_peer
    relevance 0../test/test_policy.cpp:428test insert_peer with a full list
    relevance 0../test/test_policy.cpp:429test add i2p peers
    relevance 0../test/test_policy.cpp:430test allow_i2p_mixed
    relevance 0../test/test_policy.cpp:431test insert_peer failing
    relevance 0../test/test_policy.cpp:432test IPv6
    relevance 0../test/test_policy.cpp:433test connect_to_peer() failing
    relevance 0../test/test_policy.cpp:434test connection_closed
    relevance 0../test/test_policy.cpp:435test recalculate connect candidates
    relevance 0../test/test_policy.cpp:436add tests here
    relevance 0../test/test_primitives.cpp:213test the case where we have > 120 samples (and have the base delay actually be updated)
    relevance 0../test/test_primitives.cpp:214test the case where a sample is lower than the history entry but not lower than the base
    relevance 0../test/test_primitives.cpp:213test the case where we have > 120 samples (and have the base delay actually be updated)
    relevance 0../test/test_primitives.cpp:214test the case where a sample is lower than the history entry but not lower than the base
    relevance 0../test/test_rss.cpp:136verify some key state is saved in 'state'
    relevance 0../test/test_rss.cpp:136verify some key state is saved in 'state'
    relevance 0../test/test_ssl.cpp:377test using a signed certificate with the wrong info-hash in DN
    relevance 0../test/test_ssl.cpp:377test using a signed certificate with the wrong info-hash in DN
    relevance 0../test/test_ssl.cpp:475also test using a hash that refers to a valid torrent but that differs from the SNI hash
    relevance 0../test/test_ssl.cpp:475also test using a hash that refers to a valid torrent but that differs from the SNI hash
    relevance 0../test/test_torrent.cpp:132wait for an alert rather than just waiting 10 seconds. This is kind of silly
    relevance 0../test/test_torrent.cpp:132wait for an alert rather than just waiting 10 seconds. This is kind of silly
    relevance 0../test/test_torrent_parse.cpp:114test remap_files
    relevance 0../test/test_torrent_parse.cpp:115merkle torrents. specifically torrent_info::add_merkle_nodes and torrent with "root hash"
    relevance 0../test/test_torrent_parse.cpp:116torrent with 'p' (padfile) attribute
    relevance 0../test/test_torrent_parse.cpp:117torrent with 'h' (hidden) attribute
    relevance 0../test/test_torrent_parse.cpp:118torrent with 'x' (executable) attribute
    relevance 0../test/test_torrent_parse.cpp:119torrent with 'l' (symlink) attribute
    relevance 0../test/test_torrent_parse.cpp:120creating a merkle torrent (torrent_info::build_merkle_list)
    relevance 0../test/test_torrent_parse.cpp:121torrent with multiple trackers in multiple tiers, making sure we shuffle them (how do you test shuffling?, load it multiple times and make sure it's in different order at least once)
    relevance 0../test/test_torrent_parse.cpp:114test remap_files
    relevance 0../test/test_torrent_parse.cpp:115merkle torrents. specifically torrent_info::add_merkle_nodes and torrent with "root hash"
    relevance 0../test/test_torrent_parse.cpp:116torrent with 'p' (padfile) attribute
    relevance 0../test/test_torrent_parse.cpp:117torrent with 'h' (hidden) attribute
    relevance 0../test/test_torrent_parse.cpp:118torrent with 'x' (executable) attribute
    relevance 0../test/test_torrent_parse.cpp:119torrent with 'l' (symlink) attribute
    relevance 0../test/test_torrent_parse.cpp:120creating a merkle torrent (torrent_info::build_merkle_list)
    relevance 0../test/test_torrent_parse.cpp:121torrent with multiple trackers in multiple tiers, making sure we shuffle them (how do you test shuffling?, load it multiple times and make sure it's in different order at least once)
    relevance 0../test/test_tracker.cpp:198test parse peers6
    relevance 0../test/test_tracker.cpp:199test parse tracker-id
    relevance 0../test/test_tracker.cpp:200test parse failure-reason
    relevance 0../test/test_tracker.cpp:201test all failure paths invalid bencoding not a dictionary no files entry in scrape response no info-hash entry in scrape response malformed peers in peer list of dictionaries uneven number of bytes in peers and peers6 string responses
    relevance 0../test/test_tracker.cpp:198test parse peers6
    relevance 0../test/test_tracker.cpp:199test parse tracker-id
    relevance 0../test/test_tracker.cpp:200test parse failure-reason
    relevance 0../test/test_tracker.cpp:201test all failure paths invalid bencoding not a dictionary no files entry in scrape response no info-hash entry in scrape response malformed peers in peer list of dictionaries uneven number of bytes in peers and peers6 string responses
    relevance 0../test/test_upnp.cpp:100store the log and verify that some key messages are there
    relevance 0../test/test_upnp.cpp:100store the log and verify that some key messages are there
    relevance 0../test/web_seed_suite.cpp:373file hashes don't work with the new torrent creator reading async
    relevance 0../test/web_seed_suite.cpp:373file hashes don't work with the new torrent creator reading async
    relevance 0../src/block_cache.cpp:884it's somewhat expensive to iterate over this linked list. Presumably because of the random access of memory. It would be nice if pieces with no evictable blocks weren't in this list
    relevance 0../src/block_cache.cpp:884it's somewhat expensive to iterate over this linked list. Presumably because of the random access of memory. It would be nice if pieces with no evictable blocks weren't in this list
    relevance 0../src/block_cache.cpp:948this should probably only be done every n:th time
    relevance 0../src/block_cache.cpp:1720create a holder for refcounts that automatically decrement
    relevance 0../src/bt_peer_connection.cpp:645this could be optimized using knuth morris pratt
    relevance 0../src/bt_peer_connection.cpp:645this could be optimized using knuth morris pratt
    relevance 0../src/bt_peer_connection.cpp:2216if we're finished, send upload_only message
    relevance 0../src/bt_peer_connection.cpp:2216if we're finished, send upload_only message
    relevance 0../src/disk_io_thread.cpp:921instead of doing a lookup each time through the loop, save cached_piece_entry pointers with piece_refcount incremented to pin them
    relevance 0../src/choker.cpp:332optimize this using partial_sort or something. We don't need to sort the entire list
    relevance 0../src/choker.cpp:335make the comparison function a free function and move it into this cpp file
    relevance 0../src/choker.cpp:340make configurable
    relevance 0../src/choker.cpp:354make configurable
    relevance 0../src/disk_io_thread.cpp:921instead of doing a lookup each time through the loop, save cached_piece_entry pointers with piece_refcount incremented to pin them
    relevance 0../src/disk_io_thread.cpp:1132instead of doing this. pass in the settings to each storage_interface call. Each disk thread could hold its most recent understanding of the settings in a shared_ptr, and update it every time it wakes up from a job. That way each access to the settings won't require a mutex to be held.
    relevance 0../src/disk_io_thread.cpp:1132instead of doing this. pass in the settings to each storage_interface call. Each disk thread could hold its most recent understanding of the settings in a shared_ptr, and update it every time it wakes up from a job. That way each access to the settings won't require a mutex to be held.
    relevance 0../src/disk_io_thread.cpp:1160a potentially more efficient solution would be to have a special queue for retry jobs, that's only ever run when a job completes, in any thread. It would only work if m_outstanding_jobs > 0
    relevance 0../src/disk_io_thread.cpp:1160a potentially more efficient solution would be to have a special queue for retry jobs, that's only ever run when a job completes, in any thread. It would only work if m_outstanding_jobs > 0
    relevance 0../src/disk_io_thread.cpp:1174it should clear the hash state even when there's an error, right?
    relevance 0../src/disk_io_thread.cpp:1174it should clear the hash state even when there's an error, right?
    relevance 0../src/disk_io_thread.cpp:1871maybe the tailqueue_iterator should contain a pointer-pointer instead and have an unlink function
    relevance 0../src/disk_io_thread.cpp:1871maybe the tailqueue_iterator should contain a pointer-pointer instead and have an unlink function
    relevance 0../src/disk_io_thread.cpp:2126this is potentially very expensive. One way to solve it would be to have a fence for just this one piece.
    relevance 0../src/disk_io_thread.cpp:2126this is potentially very expensive. One way to solve it would be to have a fence for just this one piece.
    relevance 0../src/disk_io_thread.cpp:2387we should probably just hang the job on the piece and make sure the hasher gets kicked
    relevance 0../src/disk_io_thread.cpp:2387we should probably just hang the job on the piece and make sure the hasher gets kicked
    relevance 0../src/disk_io_thread.cpp:2457introduce a holder class that automatically increments and decrements the piece_refcount
    relevance 0../src/disk_io_thread.cpp:2457introduce a holder class that automatically increments and decrements the piece_refcount
    relevance 0../src/disk_io_thread.cpp:2699it would be nice to not have to lock the mutex every turn through this loop
    relevance 0../src/disk_io_thread.cpp:2699it would be nice to not have to lock the mutex every turn through this loop
    relevance 0../src/http_tracker_connection.cpp:93support authentication (i.e. user name and password) in the URL
    relevance 0../src/http_tracker_connection.cpp:194support this somehow
    relevance 0../src/http_tracker_connection.cpp:194support this somehow
    relevance 0../src/metadata_transfer.cpp:359this is not safe. The torrent could be unloaded while we're still sending the metadata
    relevance 0../src/packet_buffer.cpp:176use compare_less_wrap for this comparison as well
    relevance 0../src/packet_buffer.cpp:176use compare_less_wrap for this comparison as well
    relevance 0../src/part_file.cpp:252what do we do if someone is currently reading from the disk from this piece? does it matter? Since we won't actively erase the data from disk, but it may be overwritten soon, it's probably not that big of a deal
    relevance 0../src/part_file.cpp:252what do we do if someone is currently reading from the disk from this piece? does it matter? Since we won't actively erase the data from disk, but it may be overwritten soon, it's probably not that big of a deal
    relevance 0../src/part_file.cpp:344instead of rebuilding the whole file header and flushing it, update the slot entries as we go
    relevance 0../src/peer_connection.cpp:1190this should be the global download rate
    relevance 0../src/peer_connection.cpp:1029this should be the global download rate
    relevance 0../src/peer_connection.cpp:3416sort the allowed fast set in priority order
    relevance 0../src/peer_connection.cpp:3255sort the allowed fast set in priority order
    relevance 0../src/piece_picker.cpp:2407when expanding pieces for cache stripe reasons, the !downloading condition doesn't make much sense
    relevance 0../src/piece_picker.cpp:2407when expanding pieces for cache stripe reasons, the !downloading condition doesn't make much sense
    relevance 0../src/session_impl.cpp:532there's no rule here to make uTP connections not have the global or local rate limits apply to it. This used to be the default.
    relevance 0../src/session_impl.cpp:533there's no rule here to make uTP connections not have the global or local rate limits apply to it. This used to be the default.
    relevance 0../src/session_impl.cpp:1744instead of having a special case for this, just make the default listen interfaces be "0.0.0.0:6881,[::1]:6881" and use the generic path. That would even allow for not listening at all.
    relevance 0../src/session_impl.cpp:1748instead of having a special case for this, just make the default listen interfaces be "0.0.0.0:6881,[::1]:6881" and use the generic path. That would even allow for not listening at all.
    relevance 0../src/session_impl.cpp:2621should this function take a shared_ptr instead?
    relevance 0../src/session_impl.cpp:2619should this function take a shared_ptr instead?
    relevance 0../src/session_impl.cpp:2975have a separate list for these connections, instead of having to loop through all of them
    relevance 0../src/session_impl.cpp:2973have a separate list for these connections, instead of having to loop through all of them
    relevance 0../src/session_impl.cpp:3016this should apply to all bandwidth channels
    relevance 0../src/session_impl.cpp:3014this should apply to all bandwidth channels
    relevance 0../src/session_impl.cpp:3502these 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.
    relevance 0../src/session_impl.cpp:3500these 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.
    relevance 0../src/session_impl.cpp:3575allow extensions to sort torrents for queuing
    relevance 0../src/session_impl.cpp:3747use a lower limit than m_settings.connections_limit to allocate the to 10% or so of connection slots for incoming connections
    relevance 0../src/session_impl.cpp:3890post a message to have this happen immediately instead of waiting for the next tick
    relevance 0../src/session_impl.cpp:3944make configurable
    relevance 0../src/session_impl.cpp:3958make configurable
    relevance 0../src/session_impl.cpp:4037this should be called for all peers!
    relevance 0../src/session_impl.cpp:3935this should be called for all peers!
    relevance 0../src/session_impl.cpp:4452it 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
    relevance 0../src/session_impl.cpp:4336it 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
    relevance 0../src/storage.cpp:710make this more generic to not just work if files have been renamed, but also if they have been merged into a single file for instance maybe use the same format as .torrent files and reuse some code from torrent_info
    relevance 0../src/storage.cpp:1006if everything moves OK, except for the partfile we currently won't update the save path, which breaks things. it would probably make more sense to give up on the partfile
    relevance 0../src/storage.cpp:1006if everything moves OK, except for the partfile we currently won't update the save path, which breaks things. it would probably make more sense to give up on the partfile
    relevance 0../src/torrent.cpp:491if the existing torrent doesn't have metadata, insert the metadata we just downloaded into it.
    relevance 0../src/torrent.cpp:491if the existing torrent doesn't have metadata, insert the metadata we just downloaded into it.
    relevance 0../src/torrent.cpp:641if the existing torrent doesn't have metadata, insert the metadata we just downloaded into it.
    relevance 0../src/torrent.cpp:641if the existing torrent doesn't have metadata, insert the metadata we just downloaded into it.
    relevance 0../src/torrent.cpp:1446is verify_peer_cert called once per certificate in the chain, and this function just tells us which depth we're at right now? If so, the comment makes sense. any certificate that isn't the leaf (i.e. the one presented by the peer) should be accepted automatically, given preverified is true. The leaf certificate need to be verified to make sure its DN matches the info-hash
    relevance 0../src/torrent.cpp:1446is verify_peer_cert called once per certificate in the chain, and this function just tells us which depth we're at right now? If so, the comment makes sense. any certificate that isn't the leaf (i.e. the one presented by the peer) should be accepted automatically, given preverified is true. The leaf certificate need to be verified to make sure its DN matches the info-hash
    relevance 0../src/torrent.cpp:1838instead of creating the picker up front here, maybe this whole section should move to need_picker()
    relevance 0../src/torrent.cpp:1838instead of creating the picker up front here, maybe this whole section should move to need_picker()
    relevance 0../src/torrent.cpp:2034there may be peer extensions relying on the torrent extension still being alive. Only do this if there are no peers. And when the last peer is disconnected, if the torrent is unloaded, clear the extensions m_extensions.clear();
    relevance 0../src/torrent.cpp:2034there may be peer extensions relying on the torrent extension still being alive. Only do this if there are no peers. And when the last peer is disconnected, if the torrent is unloaded, clear the extensions m_extensions.clear();
    relevance 0../src/torrent.cpp:2709this pattern is repeated in a few places. Factor this into a function and generalize the concept of a torrent having a dedicated listen port
    relevance 0../src/torrent.cpp:3483add one peer per IP the hostname resolves to
    relevance 0../src/torrent.cpp:3482add one peer per IP the hostname resolves to
    relevance 0../src/torrent.cpp:4473update suggest_piece?
    relevance 0../src/torrent.cpp:4616really, we should just keep the picker around in this case to maintain the availability counters
    relevance 0../src/torrent.cpp:6541make this more generic to not just work if files have been renamed, but also if they have been merged into a single file for instance maybe use the same format as .torrent files and reuse some code from torrent_info The mapped_files needs to be read both in the network thread and in the disk thread, since they both have their own mapped files structures which are kept in sync
    relevance 0../src/torrent.cpp:6538make this more generic to not just work if files have been renamed, but also if they have been merged into a single file for instance maybe use the same format as .torrent files and reuse some code from torrent_info The mapped_files needs to be read both in the network thread and in the disk thread, since they both have their own mapped files structures which are kept in sync
    relevance 0../src/torrent.cpp:6701if this is a merkle torrent and we can't restore the tree, we need to wipe all the bits in the have array, but not necessarily we might want to do a full check to see if we have all the pieces. This is low priority since almost no one uses merkle torrents
    relevance 0../src/torrent.cpp:6894make this more generic to not just work if files have been renamed, but also if they have been merged into a single file for instance. using file_base
    relevance 0../src/torrent.cpp:6891make this more generic to not just work if files have been renamed, but also if they have been merged into a single file for instance. using file_base
    relevance 0../src/torrent.cpp:8884add 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
    relevance 0../src/torrent.cpp:9849go 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
    relevance 0../src/torrent.cpp:9846go 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
    relevance 0../src/torrent.cpp:10495instead of resorting the whole list, insert the peers directly into the right place
    relevance 0../src/torrent.cpp:10492instead of resorting the whole list, insert the peers directly into the right place
    relevance 0../src/torrent_peer.cpp:176how do we deal with our external address changing?
    relevance 0../src/udp_socket.cpp:286it would be nice to detect this on posix systems also
    relevance 0../src/upnp.cpp:71listen_interface is not used. It's meant to bind the broadcast socket
    relevance 0../src/upnp.cpp:71listen_interface is not used. It's meant to bind the broadcast socket
    relevance 0../src/ut_metadata.cpp:316we really need to increment the refcounter on the torrent while this buffer is still in the peer's send buffer
    relevance 0../src/ut_metadata.cpp:316we really need to increment the refcounter on the torrent while this buffer is still in the peer's send buffer
    relevance 0../src/utp_stream.cpp:1627this loop may not be very efficient
    relevance 0../src/utp_stream.cpp:1627this loop may not be very efficient
    relevance 0../src/web_connection_base.cpp:73introduce a web-seed default class which has a low download priority
    relevance 0../src/web_connection_base.cpp:73introduce a web-seed default class which has a low download priority
    relevance 0../src/kademlia/dht_tracker.cpp:428ideally this function would be called when the put completes
    relevance 0../src/kademlia/dht_tracker.cpp:428ideally this function would be called when the put completes
    relevance 0../src/kademlia/routing_table.cpp:316instad of refreshing a bucket by using find_nodes, ping each node periodically
    relevance 0../include/libtorrent/bitfield.hpp:158rename to data() ?
    relevance 0../include/libtorrent/bitfield.hpp:158rename to data() ?
    relevance 0../include/libtorrent/block_cache.hpp:218make this 32 bits and to count seconds since the block cache was created
    relevance 0../include/libtorrent/block_cache.hpp:218make this 32 bits and to count seconds since the block cache was created
    relevance 0../include/libtorrent/config.hpp:339Make this count Unicode characters instead of bytes on windows
    relevance 0../include/libtorrent/config.hpp:339Make this count Unicode characters instead of bytes on windows
    relevance 0../include/libtorrent/debug.hpp:215rewrite this class to use FILE* instead and have a printf-like interface
    relevance 0../include/libtorrent/debug.hpp:215rewrite this class to use FILE* instead and have a printf-like interface
    relevance 0../include/libtorrent/disk_buffer_pool.hpp:128try to remove the observers, only using the async_allocate handlers
    relevance 0../include/libtorrent/disk_buffer_pool.hpp:128try to remove the observers, only using the async_allocate handlers
    relevance 0../include/libtorrent/peer_connection.hpp:216make this a raw pointer (to save size in the first cache line) and make the constructor take a raw pointer. torrent objects should always outlive their peers
    relevance 0../include/libtorrent/peer_connection.hpp:216make this a raw pointer (to save size in the first cache line) and make the constructor take a raw pointer. torrent objects should always outlive their peers
    relevance 0../include/libtorrent/peer_connection.hpp:1123factor this out into its own class with a virtual interface torrent and session should implement this interface
    relevance 0../include/libtorrent/peer_connection.hpp:1125factor this out into its own class with a virtual interface torrent and session should implement this interface
    relevance 0../include/libtorrent/peer_connection_interface.hpp:45make this interface smaller!
    relevance 0../include/libtorrent/peer_connection_interface.hpp:45make this interface smaller!
    relevance 0../include/libtorrent/performance_counters.hpp:132should keepalives be in here too? how about dont-have, share-mode, upload-only
    relevance 0../include/libtorrent/performance_counters.hpp:132should keepalives be in here too? how about dont-have, share-mode, upload-only
    relevance 0../include/libtorrent/performance_counters.hpp:408some space could be saved here by making gauges 32 bits
    relevance 0../include/libtorrent/performance_counters.hpp:409restore these to regular integers. Instead have one copy of the counters per thread and collect them at convenient synchronization points
    relevance 0../include/libtorrent/performance_counters.hpp:408some space could be saved here by making gauges 32 bits
    relevance 0../include/libtorrent/performance_counters.hpp:409restore these to regular integers. Instead have one copy of the counters per thread and collect them at convenient synchronization points
    relevance 0../include/libtorrent/piece_picker.hpp:669should this be allocated lazily?
    relevance 0../include/libtorrent/piece_picker.hpp:669should this be allocated lazily?
    relevance 0../include/libtorrent/proxy_base.hpp:171it would be nice to remember the bind port and bind once we know where the proxy is m_sock.bind(endpoint, ec);
    relevance 0../include/libtorrent/proxy_base.hpp:171it would be nice to remember the bind port and bind once we know where the proxy is m_sock.bind(endpoint, ec);
    relevance 0../include/libtorrent/session.hpp:861add get_peer_class_type_filter() as well
    relevance 0../include/libtorrent/session.hpp:861add get_peer_class_type_filter() as well
    relevance 0../include/libtorrent/settings_pack.hpp:1080deprecate this ``max_rejects`` is the number of piece requests we will reject in a row while a peer is choked before the peer is considered abusive and is disconnected.
    relevance 0../include/libtorrent/settings_pack.hpp:1075deprecate this ``max_rejects`` is the number of piece requests we will reject in a row while a peer is choked before the peer is considered abusive and is disconnected.
    relevance 0../include/libtorrent/size_type.hpp:48remove these and just use boost's types directly
    relevance 0../include/libtorrent/size_type.hpp:48remove these and just use boost's types directly
    relevance 0../include/libtorrent/torrent.hpp:1213this wastes 5 bits per file
    relevance 0../include/libtorrent/torrent.hpp:1213this wastes 5 bits per file
    relevance 0../include/libtorrent/torrent.hpp:1272These two bitfields should probably be coalesced into one
    relevance 0../include/libtorrent/torrent.hpp:1272These two bitfields should probably be coalesced into one
    relevance 0../include/libtorrent/torrent_info.hpp:124include the number of peers received from this tracker, at last announce
    relevance 0../include/libtorrent/torrent_info.hpp:124include the number of peers received from this tracker, at last announce
    relevance 0../include/libtorrent/upnp.hpp:112support using the windows API for UPnP operations as well
    relevance 0../include/libtorrent/upnp.hpp:112support using the windows API for UPnP operations as well
    relevance 0../include/libtorrent/utp_stream.hpp:395implement blocking write. Low priority since it's not used (yet)
    relevance 0../include/libtorrent/utp_stream.hpp:395implement blocking write. Low priority since it's not used (yet)
    relevance 0../include/libtorrent/kademlia/item.hpp:61since this is a public function, it should probably be moved out of this header and into one with other public functions.
    relevance 0../include/libtorrent/kademlia/item.hpp:61since this is a public function, it should probably be moved out of this header and into one with other public functions.
    relevance 0../include/libtorrent/aux_/session_impl.hpp:378move the login info into the tracker_request object
    relevance 0../include/libtorrent/aux_/session_impl.hpp:378move the login info into the tracker_request object
    relevance 0../include/libtorrent/aux_/session_impl.hpp:841should this be renamed m_outgoing_interfaces?
    relevance 0../include/libtorrent/aux_/session_impl.hpp:841should this be renamed m_outgoing_interfaces?
    relevance 0../include/libtorrent/aux_/session_impl.hpp:890replace this by a proper asio timer
    relevance 0../include/libtorrent/aux_/session_impl.hpp:895replace this by a proper asio timer
    relevance 0../include/libtorrent/aux_/session_impl.hpp:895replace this by a proper asio timer
    relevance 0../include/libtorrent/aux_/session_impl.hpp:900replace this by a proper asio timer
    relevance 0../include/libtorrent/aux_/session_impl.hpp:902replace this by a proper asio timer
    relevance 0../include/libtorrent/aux_/session_impl.hpp:907replace this by a proper asio timer
    relevance 0../include/libtorrent/aux_/session_interface.hpp:202it would be nice to not have this be part of session_interface
    relevance 0../include/libtorrent/aux_/session_interface.hpp:202it would be nice to not have this be part of session_interface
    Author: Arvid Norberg, arvid@libtorrent.org
    Version:1.0.0
    1.1.0

    The following troubleshooting chart may help in finding out why torrents fail