libtorrent todo-list

2 urgent 39 important 50 relevant 4 feasible 192 notes
relevance 4../test/test_dht.cpp:1250pass in the actual salt as a parameter
relevance 4../test/test_dht.cpp:2138pass in th actual salt as the argument
relevance 3../test/test_dht.cpp:118make the mock_socket hold a reference to the list of where to record packets instead of having a global variable
relevance 3../test/test_dht.cpp:127ideally the mock_socket would contain this queue of packets, to make tests independent
relevance 3../test/test_dht.cpp:1207split this up into smaller tests
relevance 3../test/test_dht.cpp:2607use dht_test_setup class to simplify the node setup
relevance 3../test/test_dht.cpp:3152use dht_test_setup class to simplify the node setup
relevance 3../test/test_dht.cpp:3251use dht_test_setup class to simplify the node setup
relevance 3../test/test_dht.cpp:3344use dht_test_setup class to simplify the node setup
relevance 3../src/torrent.cpp:418we could probably get away with just saving a few fields here
relevance 3../src/torrent.cpp:714assert there are no outstanding async operations on this torrent
relevance 3../src/torrent.cpp:1326there's some duplication between this function and peer_connection::incoming_piece(). is there a way to merge something?
relevance 3../src/torrent.cpp:3951this could probably be pulled out into a free function
relevance 3../src/torrent.cpp:4886should this alert have an error code in it?
relevance 3../src/torrent.cpp:4956this should return optional<>. piece index -1 should not be allowed
relevance 3../src/web_peer_connection.cpp:199this should be an optional, piece index -1 should not be allowed
relevance 3../src/web_peer_connection.cpp:419do we really need a special case here? wouldn't the multi-file case handle single file torrents correctly too?
relevance 3../src/web_peer_connection.cpp:504file_index_t should not allow negative values
relevance 3../src/web_peer_connection.cpp:695this could be made more efficient for the case when we use an HTTP proxy. Then we wouldn't need to add new web seeds to the torrent, we could just make the redirect table contain full URLs.
relevance 3../src/peer_connection.cpp:3119instead of having to ask the torrent whether it's in graceful pause mode or not, the peers should keep that state (and the torrent should update them when it enters graceful pause). When a peer enters graceful pause mode, it should cancel all outstanding requests and clear its request queue.
relevance 3../src/peer_connection.cpp:4027once peers are properly put in graceful pause mode, they can cancel all outstanding requests and this test can be removed.
relevance 3../src/peer_connection.cpp:4713new_piece should be an optional. piece index -1 should not be allowed
relevance 3../src/ut_metadata.cpp:268use the aux::write_* functions and the span here instead, it will fit better with send_buffer()
relevance 3../src/session_handle.cpp:672expose the sequence_number, public_key, secret_key and signature types to the client
relevance 3../src/session_impl.cpp:1139closing the udp sockets here means that the uTP connections cannot be closed gracefully
relevance 3../src/session_impl.cpp:1633the logic in this if-block should be factored out into a separate function. At least most of it
relevance 3../src/session_impl.cpp:2601it would be neat if the utp socket manager would handle ICMP errors too
relevance 3../src/session_impl.cpp:4143it would probably make sense to have a separate list of peers that are eligible for optimistic unchoke, similar to the torrents perhaps this could even iterate over the pool allocators of torrent_peer objects. It could probably be done in a single pass and collect the n best candidates. maybe just a queue of peers would make even more sense, just pick the next peer in the queue for unchoking. It would be O(1).
relevance 3../src/session_impl.cpp:4166peers should know whether their torrent is paused or not, instead of having to ask it over and over again
relevance 3../src/session_impl.cpp:4412there should be a pre-calculated list of all peers eligible for unchoking
relevance 3../src/session_impl.cpp:6121use public_key here instead of std::array
relevance 3../src/kademlia/rpc_manager.cpp:71move this into it's own .cpp file
relevance 3../include/libtorrent/torrent.hpp:1438factor out predictive pieces and all operations on it into a separate class (to use as memeber here instead)
relevance 3../include/libtorrent/torrent.hpp:1498factor out the links (as well as update_list() to a separate class that torrent can inherit)
relevance 3../include/libtorrent/pe_crypto.hpp:72dh_key_exchange should probably move into its own file
relevance 3../include/libtorrent/web_peer_connection.hpp:119if we make this be a disk_buffer_holder instead we would save a copy use allocate_disk_receive_buffer and release_disk_receive_buffer
relevance 3../include/libtorrent/torrent_handle.hpp:535unify url_seed and http_seed with just web_seed, using the web_seed_entry.
relevance 3../include/libtorrent/stat.hpp:257everything but payload counters and rates could probably be removed from here
relevance 3../include/libtorrent/enum_net.hpp:164use string_view for device_name
relevance 3../include/libtorrent/kademlia/routing_table.hpp:153to improve memory locality and scanning performance, turn the routing table into a single vector with boundaries for the nodes instead. Perhaps replacement nodes should be in a separate vector.
relevance 3../include/libtorrent/aux_/storage_utils.hpp:54remove this typedef, and use span for disk write operations
relevance 2../test/test_dht.cpp:1642test num_global_nodes
relevance 2../test/test_dht.cpp:1643test need_refresh
relevance 2../test/test_dht.cpp:2828split this up into smaller test cases
relevance 2../test/test_storage.cpp:639split this test up into smaller parts
relevance 2../test/test_piece_picker.cpp:2825test picking with partial pieces and other peers present so that both backup_pieces and backup_pieces2 are used
relevance 2../src/torrent.cpp:503post alert
relevance 2../src/torrent.cpp:1842add a unit test where we don't have metadata, connect to a peer that sends a bitfield that's too large, then we get the metadata
relevance 2../src/torrent.cpp:4473use chrono type for time duration
relevance 2../src/torrent.cpp:4900abort lookups this torrent has made via the session host resolver interface
relevance 2../src/torrent.cpp:8008if peer is a really good peer, maybe we shouldn't disconnect it perhaps this logic should be disabled if we have too many idle peers (with some definition of idle)
relevance 2../src/bdecode.cpp:826attempt to simplify this implementation by embracing the span
relevance 2../src/web_peer_connection.cpp:626just 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 pad files will make it complicated
relevance 2../src/peer_connection.cpp:2548this should probably be based on time instead of number of request messages. For a very high throughput connection, 300 may be a legitimate number of requests to have in flight when getting choked
relevance 2../src/peer_connection.cpp:3293since 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 2../src/peer_connection.cpp:4958use 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/alert_manager.cpp:80keep a count of the number of threads waiting. Only if it's > 0 notify them
relevance 2../src/peer_list.cpp:537it would be nice if there was a way to iterate over these torrent_peer objects in the order they are allocated in the pool instead. It would probably be more efficient
relevance 2../src/instantiate_connection.cpp:44peer_connection and tracker_connection should probably be flags
relevance 2../src/alert.cpp:2021the salt here is allocated on the heap. It would be nice to allocate in the stack_allocator
relevance 2../src/udp_tracker_connection.cpp:81support authentication here. tracker_req().auth
relevance 2../src/upnp.cpp:106use boost::asio::ip::network instead of netmask
relevance 2../src/tracker_manager.cpp:369implement
relevance 2../src/escape_string.cpp:194this should probably be moved into string_util.cpp
relevance 2../src/path.cpp:429test this on a FAT volume to see what error we get!
relevance 2../src/storage_utils.cpp:287technically, this is where the transaction of moving the files is completed. This is where the new save_path should be committed. If there is an error in the code below, that should not prevent the new save path to be set. Maybe it would make sense to make the save_path an in-out parameter
relevance 2../src/storage_utils.cpp:479is this risky? The upper layer will assume we have the whole file. Perhaps we should verify that at least the size of the file is correct
relevance 2../src/http_tracker_connection.cpp:479returning a bool here is redundant. Instead this function should return the peer_entry
relevance 2../src/piece_picker.cpp:2003make the 2048 limit configurable
relevance 2../src/piece_picker.cpp:2600the first_block returned here is the largest free range, not the first-fit range, which would be better
relevance 2../src/piece_picker.cpp:3485it would be nice if this could be folded into lock_piece() the main distinction is that this also maintains the m_num_passed counter and the passed_hash_check member Is there ever a case where we call write failed without also locking the piece? Perhaps write_failed() should imply locking it.
relevance 2../src/session_impl.cpp:598is there a reason not to move all of this into init()? and just post it to the io_context?
relevance 2../src/session_impl.cpp:760the ip filter should probably be saved here too
relevance 2../src/session_impl.cpp:3870make 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/session_impl.cpp:5503this function should be removed and users need to deal with the more generic case of having multiple listen ports
relevance 2../src/session_impl.cpp:5543this function should be removed and users need to deal with the more generic case of having multiple ssl ports
relevance 2../src/session_impl.cpp:6375this should be factored into the udp socket, so we only have the code once
relevance 2../src/kademlia/node.cpp:684it would be nice to have a bias towards node-id prefixes that are missing in the bucket
relevance 2../src/kademlia/node.cpp:757use the non deprecated function instead of this one
relevance 2../src/kademlia/dht_storage.cpp:87make this configurable in dht_settings
relevance 2../src/kademlia/routing_table.cpp:305use the non deprecated function instead of this one
relevance 2../src/kademlia/routing_table.cpp:940move the lowest priority nodes to the replacement bucket
relevance 2../include/libtorrent/piece_picker.hpp:647having 8 priority levels is probably excessive. It should probably be changed to 3 levels + dont-download
relevance 2../include/libtorrent/proxy_base.hpp:298use the resolver interface that has a built-in cache
relevance 2../include/libtorrent/peer_connection.hpp:996this should really be a circular buffer
relevance 2../include/libtorrent/peer_connection.hpp:1086rename this target queue size
relevance 2../include/libtorrent/enum_net.hpp:196this could be done more efficiently by just looking up the interface with the given name, maybe even with if_nametoindex()
relevance 2../include/libtorrent/socks5_stream.hpp:153add async_connect() that takes a hostname and port as well
relevance 2../include/libtorrent/aux_/session_interface.hpp:127make this interface a lot smaller. It could be split up into several smaller interfaces. Each subsystem could then limit the size of the mock object to test it.
relevance 2../include/libtorrent/aux_/session_interface.hpp:136the IP voting mechanism should be factored out to its own class, not part of the session and these constants should move too
relevance 2../include/libtorrent/aux_/chained_buffer.hpp:60this type should probably be renamed to send_buffer
relevance 1../src/torrent.cpp:1125make 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:8371should 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/session_impl.cpp:5695report the proper address of the router as the source IP of this vote of our external address, instead of the empty address
relevance 1../include/libtorrent/ip_voter.hpp:130have one instance per possible subnet, 192.168.x.x, 10.x.x.x, etc.
relevance 0../test/test_dht.cpp:472check to make sure the "best" items are stored
relevance 0../test/test_dht.cpp:3223this won't work because the second node isn't pinged so it wont be added to the routing table
relevance 0../test/test_dht.cpp:4081test obfuscated_get_peers
relevance 0../test/test_resume.cpp:582test what happens when loading a resume file with both piece priorities and file priorities (file prio should take precedence)
relevance 0../test/test_resume.cpp:585make sure a resume file only ever contain file priorities OR piece priorities. Never both.
relevance 0../test/test_resume.cpp:588generally save
relevance 0../test/test_resume.cpp:911test all other resume flags here too. This would require returning more than just the torrent_status from test_resume_flags. Also http seeds and trackers for instance
relevance 0../test/test_resume.cpp:1683test all other resume flags here too. This would require returning more than just the torrent_status from test_resume_flags. Also http seeds and trackers for instance
relevance 0../test/test_torrent_info.cpp:455test remap_files
relevance 0../test/test_torrent_info.cpp:456torrent with 'p' (padfile) attribute
relevance 0../test/test_torrent_info.cpp:457torrent with 'h' (hidden) attribute
relevance 0../test/test_torrent_info.cpp:458torrent with 'x' (executable) attribute
relevance 0../test/test_torrent_info.cpp:459torrent with 'l' (symlink) attribute
relevance 0../test/test_torrent_info.cpp:460torrent 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_info.cpp:463torrents with a zero-length name
relevance 0../test/test_torrent_info.cpp:464torrent with a non-dictionary info-section
relevance 0../test/test_torrent_info.cpp:465torrents with DHT nodes
relevance 0../test/test_torrent_info.cpp:466torrent with url-list as a single string
relevance 0../test/test_torrent_info.cpp:467torrent with http seed as a single string
relevance 0../test/test_torrent_info.cpp:468torrent with a comment
relevance 0../test/test_torrent_info.cpp:469torrent with an SSL cert
relevance 0../test/test_torrent_info.cpp:470torrent with attributes (executable and hidden)
relevance 0../test/test_torrent_info.cpp:471torrent_info constructor that takes an invalid bencoded buffer
relevance 0../test/test_torrent_info.cpp:472verify_encoding with a string that triggers character replacement
relevance 0../test/test_ssl.cpp:407test using a signed certificate with the wrong info-hash in DN
relevance 0../test/test_ssl.cpp:509also test using a hash that refers to a valid torrent but that differs from the SNI hash
relevance 0../test/test_timestamp_history.cpp:54test the case where we have > 120 samples (and have the base delay actually be updated)
relevance 0../test/test_timestamp_history.cpp:55test the case where a sample is lower than the history entry but not lower than the base
relevance 0../test/test_resolve_links.cpp:95test files with different piece size (negative test)
relevance 0../test/test_resolve_links.cpp:98it would be nice to test resolving of more than just 2 files as well. like 3 single file torrents merged into one, resolving all 3 files.
relevance 0../test/test_fast_extension.cpp:1135test sending invalid requests (out of bound piece index, offsets and sizes)
relevance 0../test/test_tracker.cpp:60test scrape requests
relevance 0../test/test_tracker.cpp:61test parse peers6
relevance 0../test/test_tracker.cpp:62test parse tracker-id
relevance 0../test/test_tracker.cpp:63test parse failure-reason
relevance 0../test/test_tracker.cpp:64test all failure paths, including 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_flags.cpp:163change to a different test setup. currently always paused. test_set_after_add(torrent_flags::paused); test_unset_after_add(torrent_flags::paused);
relevance 0../test/test_flags.cpp:205this test is flaky, since the torrent will become ready before asking for the flags, and by then stop_when_ready will have been cleared test_add_and_get_flags(torrent_flags::stop_when_ready); setting stop-when-ready when already stopped has no effect.
relevance 0../test/test_flags.cpp:209change to a different test setup. currently always paused. test_set_after_add(torrent_flags::stop_when_ready);
relevance 0../test/test_merkle_tree.cpp:233use structured bindings in C++17
relevance 0../test/test_merkle_tree.cpp:938add test for load_piece_layer()
relevance 0../test/test_merkle_tree.cpp:939add test for add_hashes() with an odd number of blocks
relevance 0../test/test_merkle_tree.cpp:940add test for set_block() (setting the last block) with an odd number of blocks
relevance 0../test/test_bloom_filter.cpp:135test size()
relevance 0../test/test_bloom_filter.cpp:136test clear()
relevance 0../test/test_peer_list.cpp:1209test erasing peers
relevance 0../test/test_peer_list.cpp:1210test update_peer_port with allow_multiple_connections_per_ip and without
relevance 0../test/test_peer_list.cpp:1211test add i2p peers
relevance 0../test/test_peer_list.cpp:1212test allow_i2p_mixed
relevance 0../test/test_peer_list.cpp:1213test insert_peer failing with all error conditions
relevance 0../test/test_peer_list.cpp:1214test IPv6
relevance 0../test/test_peer_list.cpp:1215test connect_to_peer() failing
relevance 0../test/test_peer_list.cpp:1216test connection_closed
relevance 0../test/test_peer_list.cpp:1217connect candidates recalculation when incrementing failcount
relevance 0../test/test_file_storage.cpp:1208test file attributes
relevance 0../test/test_file_storage.cpp:1209test symlinks
relevance 0../test/test_upnp.cpp:156store the log and verify that some key messages are there
relevance 0../test/test_transfer.cpp:166these settings_pack tests belong in their own test
relevance 0../src/pe_crypto.cpp:60it would be nice to get the literal working
relevance 0../src/pe_crypto.cpp:71it would be nice to be able to export to a fixed width field, so we wouldn't have to shift it later
relevance 0../src/torrent.cpp:1941this could be optimized by looking up which files are complete and just look at those
relevance 0../src/torrent.cpp:1954this could be optimized by looking up which files are complete and just look at those
relevance 0../src/torrent.cpp:2715this 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:3870add one peer per IP the hostname resolves to
relevance 0../src/torrent.cpp:4562only do this if the piece size > 1 blocks This is a v2 torrent so we can request get block level hashes.
relevance 0../src/torrent.cpp:7501come up with a better way of doing this, instead of an immediately invoked lambda expression.
relevance 0../src/torrent.cpp:9091perhaps 0 should actially mean 0
relevance 0../src/torrent.cpp:9108perhaps 0 should actially mean 0
relevance 0../src/torrent.cpp:11037instead of resorting the whole list, insert the peers directly into the right place
relevance 0../src/merkle_tree.cpp:110in C++20, use std::identity
relevance 0../src/merkle_tree.cpp:319this can be optimized by using m_tree as storage to fill this tree into, and then clear it if the hashes fail
relevance 0../src/merkle_tree.cpp:367a piece outside of this range may also fail, if one of the uncle hashes is at the layer right above the block hashes
relevance 0../src/merkle_tree.cpp:447instead of overwriting the root and comparing it against hashes[], write a functions that *validates* a tree by just filling it up to the level below the root and then validates it.
relevance 0../src/merkle_tree.cpp:471this could be done more efficiently if bitfield had a function to set a range of bits
relevance 0../src/merkle_tree.cpp:514use structured binding in C++17
relevance 0../src/merkle_tree.cpp:539this could be done more efficiently if bitfield had a function to set a range of bits
relevance 0../src/ip_notifier.cpp:41simulator support
relevance 0../src/peer_connection.cpp:1091this should be the global download rate
relevance 0../src/peer_connection.cpp:3520sort the allowed fast set in priority order
relevance 0../src/part_file.cpp:300what 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:412instead of rebuilding the whole file header and flushing it, update the slot entries as we go
relevance 0../src/torrent_info.cpp:875this should be considered a failure, and the .torrent file rejected
relevance 0../src/settings_pack.cpp:305deprecate this
relevance 0../src/settings_pack.cpp:589it would be nice to reserve() these vectors up front
relevance 0../src/packet_buffer.cpp:157use compare_less_wrap for this comparison as well
relevance 0../src/performance_counters.cpp:40move stats_counter_t out of counters
relevance 0../src/performance_counters.cpp:41should bittorrent keep-alive messages have a counter too?
relevance 0../src/performance_counters.cpp:42It would be nice if this could be an internal type. default_disk_constructor depends on it now
relevance 0../src/hash_picker.cpp:309use structured bindings in C++17
relevance 0../src/web_connection_base.cpp:72introduce a web-seed default class which has a low download priority
relevance 0../src/enum_net.cpp:144in C++17, use __has_include for this. Other operating systems are likely to require this as well
relevance 0../src/enum_net.cpp:268if we get here, the caller still assumes the error code is reported via errno
relevance 0../src/enum_net.cpp:274if we get here, the caller still assumes the error code is reported via errno
relevance 0../src/utp_socket_manager.cpp:204this should not be heap allocated, sockets should be movable
relevance 0../src/ut_metadata.cpp:281we really need to increment the refcounter on the torrent while this buffer is still in the peer's send buffer
relevance 0../src/file_storage.cpp:457maybe it would be nice to have a better index here
relevance 0../src/file_storage.cpp:1242this would be more efficient if m_paths was sorted first, such that a lower path index always meant sorted-before
relevance 0../src/file_storage.cpp:1345in C++17 this could be string_view
relevance 0../src/random.cpp:141improve calling RAND_bytes multiple times, using fallback for now
relevance 0../src/mmap_disk_io.cpp:578in the future, propagate exceptions back to the handlers
relevance 0../src/mmap_disk_io.cpp:1017this is potentially very expensive. One way to solve it would be to have a fence for just this one piece. but it hardly seems worth the complexity and cost just for the edge case of receiving a corrupt piece
relevance 0../src/mmap_disk_io.cpp:1022Perhaps the job queue could be traversed and all jobs for this piece could be cancelled. If there are no threads currently writing to this piece, we could skip the fence alltogether
relevance 0../src/session.cpp:539In C++17. use if constexpr instead
relevance 0../src/create_torrent.cpp:611this can be optimized
relevance 0../src/add_torrent_params.cpp:78pre C++17, GCC and msvc does not make std::string nothrow move assignable, which means no type containing a string will be nothrow move assignable by default either static_assert(std::is_nothrow_move_assignable::value , "should be nothrow move assignable");
relevance 0../src/add_torrent_params.cpp:84it would be nice if this was nothrow default constructible static_assert(std::is_nothrow_default_constructible::value , "should be nothrow default constructible");
relevance 0../src/torrent_peer.cpp:179how do we deal with our external address changing?
relevance 0../src/alert.cpp:404move this field into tracker_alert
relevance 0../src/alert.cpp:438move this into tracker_alert
relevance 0../src/alert.cpp:464move this into tracker_alert
relevance 0../src/alert.cpp:493move this into tracker_alert
relevance 0../src/alert.cpp:532move this field into tracker_alert
relevance 0../src/alert.cpp:576move this to tracker_alert
relevance 0../src/udp_tracker_connection.cpp:633why is this a linked list?
relevance 0../src/session_handle.cpp:485in C++14, use unique_ptr and move it into the lambda
relevance 0../src/http_seed_connection.cpp:441technically, this isn't supposed to happen, but it seems to sometimes. Some of the accounting is probably wrong in certain cases
relevance 0../src/utp_stream.cpp:1467this loop is not very efficient. It could be fixed by having a separate list of sequence numbers that need resending
relevance 0../src/disabled_disk_io.cpp:106it would be nice to return a valid hash of zeroes here
relevance 0../src/magnet_uri.cpp:439what's the right number here?
relevance 0../src/choker.cpp:255make configurable
relevance 0../src/posix_part_file.cpp:337what 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/posix_part_file.cpp:425instead of rebuilding the whole file header and flushing it, update the slot entries as we go
relevance 0../src/udp_socket.cpp:659perhaps an attempt should be made to bind m_socks5_sock to the device of m_listen_socket
relevance 0../src/cpuid.cpp:131enable when aarch64 is really tested
relevance 0../src/storage_utils.cpp:223ideally, if we end up copying files because of a move across volumes, the source should not be deleted until they've all been copied. That would let us rollback with higher confidence.
relevance 0../src/storage_utils.cpp:531it would seem reasonable to, instead, set the have_pieces bits for the pieces representing these files, and resume with the normal logic
relevance 0../src/torrent_handle.cpp:589support moving files into this call
relevance 0../src/piece_picker.cpp:121find a better place for this
relevance 0../src/piece_picker.cpp:2074this could probably be optimized by incrementally calling partial_sort to sort one more element in the list. Because chances are that we'll just need a single piece, and once we've picked from it we're done. Sorting the rest of the list in that case is a waste of time.
relevance 0../src/piece_picker.cpp:2218Is it a good idea that this affinity takes precedence over piece priority?
relevance 0../src/piece_picker.cpp:2572when expanding pieces for cache stripe reasons, the !downloading condition doesn't make much sense
relevance 0../src/piece_picker.cpp:3150should 5 be configurable?
relevance 0../src/session_impl.cpp:614come up with some abstraction to do this for gnutls as well load certificates from the windows system certificate store
relevance 0../src/session_impl.cpp:1479it would be nice to reserve() these vectors up front
relevance 0../src/session_impl.cpp:1993could this function be merged with expand_unspecified_addresses? right now both listen_endpoint_t and listen_interface_t are almost identical, maybe the latter could be removed too
relevance 0../src/session_impl.cpp:2301it would probably be better to do this by having a listen-socket "version" number that gets bumped. And instead of setting a bool to disable a tracker, we set the version number that it was disabled at. This change would affect the ABI in 1.2, so should be done in 2.0 or later
relevance 0../src/session_impl.cpp:2861this size need to be capped
relevance 0../src/session_impl.cpp:2886this size need to be capped
relevance 0../src/session_impl.cpp:3578have a separate list for these connections, instead of having to loop through all of them
relevance 0../src/session_impl.cpp:3611this should apply to all bandwidth channels
relevance 0../src/session_impl.cpp:4302use a lower limit than m_settings.connections_limit to allocate the to 10% or so of connection slots for incoming connections cap this at max - 1, since we may add one below
relevance 0../src/session_impl.cpp:4447post a message to have this happen immediately instead of waiting for the next tick
relevance 0../src/session_impl.cpp:4774it 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. Perhaps the status_update_alert could even have a fixed array of n entries rather than a vector, to further improve memory locality.
relevance 0../src/session_impl.cpp:5149factor out this logic into a separate function for unit testing
relevance 0../src/session_impl.cpp:5865refactor, move the storage to dht_tracker
relevance 0../src/session_impl.cpp:6252asserts that no outstanding async operations are still in flight
relevance 0../src/load_torrent.cpp:121move the loading logic from torrent_info constructor into here
relevance 0../src/kademlia/node.cpp:1177keep the returned value to pass as a limit to write_nodes_entries when implemented
relevance 0../src/kademlia/node.cpp:1205limit number of entries in the result
relevance 0../src/kademlia/item.cpp:143implement ctor for entry from bdecode_node?
relevance 0../src/kademlia/dht_tracker.cpp:317pick the closest node rather than the first
relevance 0../src/kademlia/put_data.cpp:92what if o is not an instance of put_data_observer? This need to be redesigned for better type safety.
relevance 0../src/kademlia/routing_table.cpp:289This is temporary. For now, only report the largest routing table (of potentially multiple ones, for multi-homed systems) in next major version, break the ABI and support reporting all of them in the dht_stats_alert
relevance 0../src/kademlia/routing_table.cpp:314arvidn note when it's across IPv4 and IPv6, adding (dht_global_nodes) would make sense. in the future though, where we may have one DHT node per external interface (which may be multiple of the same address family), then it becomes a bit trickier
relevance 0../src/kademlia/routing_table.cpp:518this need to take bucket "prefix" into account. It should be unified with add_node_impl()
relevance 0../src/kademlia/node_id.cpp:66it's a little bit weird to return 159 - leading zeroes. It should probably be 160 - leading zeroes, but all other code in here is tuned to this expectation now, and it doesn't really matter (other than complexity)
relevance 0../include/libtorrent/piece_picker.hpp:802should this be allocated lazily?
relevance 0../include/libtorrent/piece_picker.hpp:877it would be more intuitive to account "wanted" pieces instead of filtered
relevance 0../include/libtorrent/torrent.hpp:280make this a raw pointer. perhaps keep the shared_ptr around further down the object to maintain an owner
relevance 0../include/libtorrent/torrent.hpp:463make graceful pause also finish all sending blocks before disconnecting
relevance 0../include/libtorrent/torrent.hpp:600make this flag a combination of the other ones
relevance 0../include/libtorrent/torrent.hpp:1396this wastes 5 bits per file
relevance 0../include/libtorrent/torrent.hpp:1711this member can probably be removed
relevance 0../include/libtorrent/peer_connection_interface.hpp:51make this interface smaller!
relevance 0../include/libtorrent/announce_entry.hpp:76include the number of peers received from this tracker, at last announce
relevance 0../include/libtorrent/i2p_stream.hpp:538make this a string_view
relevance 0../include/libtorrent/proxy_base.hpp:207it 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/socket_type.hpp:60move to aux
relevance 0../include/libtorrent/upnp.hpp:162support using the windows API for UPnP operations as well
relevance 0../include/libtorrent/hash_picker.hpp:155support batched adding of block hashes for reduced overhead?
relevance 0../include/libtorrent/string_view.hpp:40replace this by the standard string_view in C++17
relevance 0../include/libtorrent/peer_connection.hpp:218make 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:1026factor this out into its own class with a virtual interface torrent and session should implement this interface
relevance 0../include/libtorrent/identify_client.hpp:48hide this declaration when deprecated functions are disabled, and remove its internal use
relevance 0../include/libtorrent/socks5_stream.hpp:197we could bind the socket here, since we know what the target endpoint is of the proxy
relevance 0../include/libtorrent/torrent_info.hpp:729change the type to std::shared_ptr in C++17 it is used as if immutable, it cannot be const for technical reasons right now.
relevance 0../include/libtorrent/performance_counters.hpp:485some space could be saved here by making gauges 32 bits
relevance 0../include/libtorrent/performance_counters.hpp:486restore these to regular integers. Instead have one copy of the counters per thread and collect them at convenient synchronization points
relevance 0../include/libtorrent/kademlia/msg.hpp:87move this to its own .hpp/.cpp pair?
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_/deprecated.hpp:47figure out which version of clang this is supported in
relevance 0../include/libtorrent/aux_/session_interface.hpp:212it would be nice to not have this be part of session_interface
relevance 0../include/libtorrent/aux_/announce_entry.hpp:74include the number of peers received from this tracker, at last announce
relevance 0../include/libtorrent/aux_/session_impl.hpp:264make these direct members and generate shared_ptrs to them which alias the listen_socket_t shared_ptr
relevance 0../include/libtorrent/aux_/session_impl.hpp:1066replace this by a proper asio timer
relevance 0../include/libtorrent/aux_/session_impl.hpp:1071replace this by a proper asio timer
relevance 0../include/libtorrent/aux_/session_impl.hpp:1078replace this by a proper asio timer
relevance 0../include/libtorrent/aux_/pool.hpp:49ensure the alignment is good here
relevance 0../include/libtorrent/aux_/allocating_handler.hpp:317in C++17, Handler and Storage could just use "auto"
relevance 0../include/libtorrent/aux_/merkle_tree.hpp:85remove this constructor. Don't support "uninitialized" trees. This also requires not constructing these for pad-files and small files as well. So, a sparse hash list in torrent_info
relevance 0../include/libtorrent/aux_/merkle_tree.hpp:175make this a std::unique_ptr
relevance 0../include/libtorrent/aux_/utp_stream.hpp:693it would be nice to make this private