libtorrent todo-list

2 urgent 37 important 49 relevant 4 feasible 211 notes
relevance 4../test/test_dht.cpp:1245pass in the actual salt as a parameter
relevance 4../test/test_dht.cpp:2133pass in th actual salt as the argument
relevance 3../test/test_dht.cpp:95make 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:104ideally the mock_socket would contain this queue of packets, to make tests independent
relevance 3../test/test_dht.cpp:1202split this up into smaller tests
relevance 3../test/test_dht.cpp:2602use dht_test_setup class to simplify the node setup
relevance 3../test/test_dht.cpp:3147use dht_test_setup class to simplify the node setup
relevance 3../test/test_dht.cpp:3293use dht_test_setup class to simplify the node setup
relevance 3../test/test_dht.cpp:3386use dht_test_setup class to simplify the node setup
relevance 3../src/torrent.cpp:458we could probably get away with just saving a few fields here
relevance 3../src/torrent.cpp:764assert there are no outstanding async operations on this torrent
relevance 3../src/torrent.cpp:1436there's some duplication between this function and peer_connection::incoming_piece(). is there a way to merge something?
relevance 3../src/torrent.cpp:4314this could probably be pulled out into a free function
relevance 3../src/torrent.cpp:5288should this alert have an error code in it?
relevance 3../src/torrent.cpp:5352this should return optional<>. piece index -1 should not be allowed
relevance 3../src/session_impl.cpp:1105closing the udp sockets here means that the uTP connections cannot be closed gracefully
relevance 3../src/session_impl.cpp:1610the logic in this if-block should be factored out into a separate function. At least most of it
relevance 3../src/session_impl.cpp:2680it would be neat if the utp socket manager would handle ICMP errors too
relevance 3../src/session_impl.cpp:4317it 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:4340peers 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:4586there should be a pre-calculated list of all peers eligible for unchoking
relevance 3../src/session_impl.cpp:6322use public_key here instead of std::array
relevance 3../src/peer_connection.cpp:3127instead 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:4022once 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:4703new_piece should be an optional. piece index -1 should not be allowed
relevance 3../src/session_handle.cpp:643expose the sequence_number, public_key, secret_key and signature types to the client
relevance 3../src/web_peer_connection.cpp:175this should be an optional, piece index -1 should not be allowed
relevance 3../src/web_peer_connection.cpp:397do 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:491file_index_t should not allow negative values
relevance 3../src/web_peer_connection.cpp:691this 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/ut_metadata.cpp:243use the aux::write_* functions and the span here instead, it will fit better with send_buffer()
relevance 3../include/libtorrent/torrent_handle.hpp:559unify url_seed and http_seed with just web_seed, using the web_seed_entry.
relevance 3../include/libtorrent/kademlia/routing_table.hpp:130to 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_/stat.hpp:235everything but payload counters and rates could probably be removed from here
relevance 3../include/libtorrent/aux_/pe_crypto.hpp:49dh_key_exchange should probably move into its own file
relevance 3../include/libtorrent/aux_/enum_net.hpp:141use string_view for device_name
relevance 3../include/libtorrent/aux_/torrent.hpp:1477factor out predictive pieces and all operations on it into a separate class (to use as member here instead)
relevance 3../include/libtorrent/aux_/torrent.hpp:1549factor out the links (as well as update_list() to a separate class that torrent can inherit)
relevance 3../include/libtorrent/aux_/web_peer_connection.hpp:96if 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 2../test/test_piece_picker.cpp:3075test picking with partial pieces and other peers present so that both backup_pieces and backup_pieces2 are used
relevance 2../test/test_storage.cpp:824split this test up into smaller parts
relevance 2../test/test_dht.cpp:1637test num_global_nodes
relevance 2../test/test_dht.cpp:1638test need_refresh
relevance 2../test/test_dht.cpp:2823split this up into smaller test cases
relevance 2../src/tracker_manager.cpp:404implement
relevance 2../src/bdecode.cpp:813attempt to simplify this implementation by embracing the span
relevance 2../src/torrent.cpp:542post alert
relevance 2../src/torrent.cpp:1995add 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:5302abort lookups this torrent has made via the session host resolver interface
relevance 2../src/torrent.cpp:8457if 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/peer_list.cpp:515it 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/session_impl.cpp:566is 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:733the ip filter should probably be saved here too
relevance 2../src/session_impl.cpp:3980make 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:5696this 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:5736this 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:6576this should be factored into the udp socket, so we only have the code once
relevance 2../src/escape_string.cpp:171this should probably be moved into string_util.cpp
relevance 2../src/storage_utils.cpp:187technically, 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:379is 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/peer_connection.cpp:2544this 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:3307since 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:4951use 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/piece_picker.cpp:1983make the 2048 limit configurable
relevance 2../src/piece_picker.cpp:2575the first_block returned here is the largest free range, not the first-fit range, which would be better
relevance 2../src/piece_picker.cpp:3453it would be nice if this could be folded into lock_piece() the main distinction is that this also maintains the m_num_have 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/http_tracker_connection.cpp:469returning a bool here is redundant. Instead this function should return the peer_entry
relevance 2../src/udp_tracker_connection.cpp:59support authentication here. tracker_req().auth
relevance 2../src/instantiate_connection.cpp:21peer_connection and tracker_connection should probably be flags
relevance 2../src/web_peer_connection.cpp:612just 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/alert.cpp:1975the salt here is allocated on the heap. It would be nice to allocate in the stack_allocator
relevance 2../src/upnp.cpp:93use boost::asio::ip::network instead of netmask
relevance 2../src/path.cpp:410test this on a FAT volume to see what error we get!
relevance 2../src/alert_manager.cpp:52keep a count of the number of threads waiting. Only if it's > 0 notify them
relevance 2../src/kademlia/routing_table.cpp:280use the non deprecated function instead of this one
relevance 2../src/kademlia/routing_table.cpp:907move the lowest priority nodes to the replacement bucket
relevance 2../src/kademlia/node.cpp:661it would be nice to have a bias towards node-id prefixes that are missing in the bucket
relevance 2../src/kademlia/node.cpp:734use the non deprecated function instead of this one
relevance 2../src/kademlia/dht_storage.cpp:65make this configurable in dht_settings
relevance 2../include/libtorrent/socks5_stream.hpp:132add async_connect() that takes a hostname and port as well
relevance 2../include/libtorrent/aux_/piece_picker.hpp:649having 8 priority levels is probably excessive. It should probably be changed to 3 levels + dont-download
relevance 2../include/libtorrent/aux_/chained_buffer.hpp:37this type should probably be renamed to send_buffer
relevance 2../include/libtorrent/aux_/session_interface.hpp:103make 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:112the 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_/enum_net.hpp:173this could be done more efficiently by just looking up the interface with the given name, maybe even with if_nametoindex()
relevance 2../include/libtorrent/aux_/peer_connection.hpp:970this should really be a circular buffer
relevance 2../include/libtorrent/aux_/peer_connection.hpp:1060rename this target queue size
relevance 2../include/libtorrent/aux_/proxy_base.hpp:305use the resolver interface that has a built-in cache
relevance 1../src/torrent.cpp:1180make 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:8829should 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:5897report 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/aux_/ip_voter.hpp:107have one instance per possible subnet, 192.168.x.x, 10.x.x.x, etc.
relevance 0../test/test_transfer.cpp:163these settings_pack tests belong in their own test
relevance 0../test/test_torrent_info.cpp:477test remap_files
relevance 0../test/test_torrent_info.cpp:478torrent with 'p' (padfile) attribute
relevance 0../test/test_torrent_info.cpp:479torrent with 'h' (hidden) attribute
relevance 0../test/test_torrent_info.cpp:480torrent with 'x' (executable) attribute
relevance 0../test/test_torrent_info.cpp:481torrent with 'l' (symlink) attribute
relevance 0../test/test_torrent_info.cpp:482torrent 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:485torrents with a zero-length name
relevance 0../test/test_torrent_info.cpp:486torrent with a non-dictionary info-section
relevance 0../test/test_torrent_info.cpp:487torrents with DHT nodes
relevance 0../test/test_torrent_info.cpp:488torrent with url-list as a single string
relevance 0../test/test_torrent_info.cpp:489torrent with http seed as a single string
relevance 0../test/test_torrent_info.cpp:490torrent with a comment
relevance 0../test/test_torrent_info.cpp:491torrent with an SSL cert
relevance 0../test/test_torrent_info.cpp:492torrent with attributes (executable and hidden)
relevance 0../test/test_torrent_info.cpp:493torrent_info constructor that takes an invalid bencoded buffer
relevance 0../test/test_torrent_info.cpp:494verify_encoding with a string that triggers character replacement
relevance 0../test/test_tracker_list.cpp:467reset
relevance 0../test/test_tracker_list.cpp:468completed
relevance 0../test/test_tracker_list.cpp:469dont_try_again
relevance 0../test/test_bandwidth_limiter.cpp:140fix these warnings
relevance 0../test/test_fast_extension.cpp:1198test sending invalid requests (out of bound piece index, offsets and sizes)
relevance 0../test/test_upnp.cpp:133store the log and verify that some key messages are there
relevance 0../test/test_storage.cpp:1369this should take a span
relevance 0../test/test_file_storage.cpp:1388test file attributes
relevance 0../test/test_file_storage.cpp:1389test symlinks
relevance 0../test/test_resolve_links.cpp:73test files with different piece size (negative test)
relevance 0../test/test_resolve_links.cpp:76it 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_ssl.cpp:384test using a signed certificate with the wrong info-hash in DN
relevance 0../test/test_ssl.cpp:486also test using a hash that refers to a valid torrent but that differs from the SNI hash
relevance 0../test/test_timestamp_history.cpp:31test the case where we have > 120 samples (and have the base delay actually be updated)
relevance 0../test/test_timestamp_history.cpp:32test the case where a sample is lower than the history entry but not lower than the base
relevance 0../test/test_bloom_filter.cpp:112test size()
relevance 0../test/test_bloom_filter.cpp:113test clear()
relevance 0../test/test_flags.cpp:132change 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_tracker.cpp:41test scrape requests
relevance 0../test/test_tracker.cpp:42test parse tracker-id
relevance 0../test/test_tracker.cpp:43test parse failure-reason
relevance 0../test/test_tracker.cpp:44test 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_resume.cpp:591test 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:594make sure a resume file only ever contain file priorities OR piece priorities. Never both.
relevance 0../test/test_resume.cpp:597generally save
relevance 0../test/test_resume.cpp:920test 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:1674test 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_peer_list.cpp:1269test erasing peers
relevance 0../test/test_peer_list.cpp:1270test update_peer_port with allow_multiple_connections_per_ip and without
relevance 0../test/test_peer_list.cpp:1271test add i2p peers
relevance 0../test/test_peer_list.cpp:1272test allow_i2p_mixed
relevance 0../test/test_peer_list.cpp:1273test insert_peer failing with all error conditions
relevance 0../test/test_peer_list.cpp:1274test IPv6
relevance 0../test/test_peer_list.cpp:1275test connect_to_peer() failing
relevance 0../test/test_peer_list.cpp:1276test connection_closed
relevance 0../test/test_peer_list.cpp:1277connect candidates recalculation when incrementing failcount
relevance 0../test/test_merkle_tree.cpp:971add test for load_piece_layer()
relevance 0../test/test_merkle_tree.cpp:972add test for add_hashes() with an odd number of blocks
relevance 0../test/test_merkle_tree.cpp:973add test for set_block() (setting the last block) with an odd number of blocks
relevance 0../test/test_dht.cpp:467check to make sure the "best" items are stored
relevance 0../test/test_dht.cpp:3218this 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:4128test obfuscated_get_peers
relevance 0../src/file.cpp:183if we have more than 1 buffer, coalesce into a single buffer and a single call
relevance 0../src/tracker_manager.cpp:316introduce a setting for max_offers
relevance 0../src/utp_socket_manager.cpp:180this should not be heap allocated, sockets should be movable
relevance 0../src/random.cpp:117improve calling RAND_bytes multiple times, using fallback for now
relevance 0../src/merkle_tree.cpp:88in C++20, use std::identity
relevance 0../src/merkle_tree.cpp:307this 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:355a 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:435instead 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:459this could be done more efficiently if bitfield had a function to set a range of bits
relevance 0../src/merkle_tree.cpp:523this could be done more efficiently if bitfield had a function to set a range of bits
relevance 0../src/posix_part_file.cpp:316what 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:408instead of rebuilding the whole file header and flushing it, update the slot entries as we go
relevance 0../src/smart_ban.cpp:158replace with std::erase_if() once we require C++20
relevance 0../src/udp_socket.cpp:643perhaps an attempt should be made to bind m_socks5_sock to the device of m_listen_socket
relevance 0../src/disk_cache.cpp:705pass the block offset as a parameter instead of computing it like this
relevance 0../src/settings_pack.cpp:285deprecate this
relevance 0../src/settings_pack.cpp:574it would be nice to reserve() these vectors up front
relevance 0../src/fingerprint.cpp:55the fingerprint constructor should take a string_view
relevance 0../src/tracker_list.cpp:83if this throws, new_ae needs to be freed
relevance 0../src/tracker_list.cpp:93if this throws, new_ae needs to be freed
relevance 0../src/torrent.cpp:2094this could be optimized by looking up which files are complete and just look at those
relevance 0../src/torrent.cpp:2108this could be optimized by looking up which files are complete and just look at those
relevance 0../src/torrent.cpp:2879this 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:3224it would be nice to raise the abstraction level of the tracker_list or trackers a bit here
relevance 0../src/torrent.cpp:3758move this into a function on tracker_list
relevance 0../src/torrent.cpp:3852the destination string should be base64 decoded and sha256 hashed to form the destination address and store that in the i2p_peer object directly
relevance 0../src/torrent.cpp:4176store i2p addresses as a 32 byte sha256 hash in the i2p_peer object, rather than resolving it into the full vase64 destination. We should keep the full destination as a cache in the i2p_peer object still.
relevance 0../src/torrent.cpp:4233add one peer per IP the hostname resolves to
relevance 0../src/torrent.cpp:4951only 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:7907come up with a better way of doing this, instead of an immediately invoked lambda expression.
relevance 0../src/torrent.cpp:9566perhaps 0 should actually mean 0
relevance 0../src/torrent.cpp:9583perhaps 0 should actually mean 0
relevance 0../src/torrent.cpp:11523instead of resorting the whole list, insert the peers directly into the right place
relevance 0../src/session_impl.cpp:582come 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:1454it would be nice to reserve() these vectors up front
relevance 0../src/session_impl.cpp:1989could 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:2940this size need to be capped
relevance 0../src/session_impl.cpp:2965this size need to be capped
relevance 0../src/session_impl.cpp:3688have a separate list for these connections, instead of having to loop through all of them
relevance 0../src/session_impl.cpp:3721this should apply to all bandwidth channels
relevance 0../src/session_impl.cpp:4476use 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:4621post a message to have this happen immediately instead of waiting for the next tick
relevance 0../src/session_impl.cpp:4948it 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:5342factor out this logic into a separate function for unit testing
relevance 0../src/session_impl.cpp:6070refactor, move the storage to dht_tracker
relevance 0../src/session_impl.cpp:6453asserts that no outstanding async operations are still in flight
relevance 0../src/resolve_duplicate_filenames.cpp:158this can be more efficient for v2 torrents
relevance 0../src/torrent_info.cpp:1635collections
relevance 0../src/torrent_info.cpp:1636similar
relevance 0../src/storage_utils.cpp:123ideally, 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:431it 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/session.cpp:261start() should just use flags out of the session_params object,
relevance 0../src/peer_connection.cpp:1071this should be the global download rate
relevance 0../src/peer_connection.cpp:1174store the sah256 hash of the destination in the i2p_peer struct, so we don't have to recompute it every time
relevance 0../src/peer_connection.cpp:3534sort the allowed fast set in priority order
relevance 0../src/piece_picker.cpp:100find a better place for this
relevance 0../src/piece_picker.cpp:2053this 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:2195Is it a good idea that this affinity takes precedence over piece priority?
relevance 0../src/piece_picker.cpp:2547when expanding pieces for cache stripe reasons, the !downloading condition doesn't make much sense
relevance 0../src/piece_picker.cpp:3119should 5 be configurable?
relevance 0../src/udp_tracker_connection.cpp:610why is this a linked list?
relevance 0../src/web_connection_base.cpp:50introduce a web-seed default class which has a low download priority
relevance 0../src/i2p_pex.cpp:400factor this out into "sliding window"? It's shared with ut_pex
relevance 0../src/part_file.cpp:294what 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:405instead of rebuilding the whole file header and flushing it, update the slot entries as we go
relevance 0../src/performance_counters.cpp:17move stats_counter_t out of counters
relevance 0../src/performance_counters.cpp:18should bittorrent keep-alive messages have a counter too?
relevance 0../src/performance_counters.cpp:19It would be nice if this could be an internal type. default_disk_constructor depends on it now
relevance 0../src/torrent_peer.cpp:167how do we deal with our external address changing?
relevance 0../src/add_torrent_params.cpp:31it 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/mmap_disk_io.cpp:377in the future, propagate exceptions back to the handlers
relevance 0../src/mmap_disk_io.cpp:856this 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:861Perhaps 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 altogether
relevance 0../src/alert.cpp:511is it reasonable to just hard-code this to V1?
relevance 0../src/packet_buffer.cpp:134use compare_less_wrap for this comparison as well
relevance 0../src/magnet_uri.cpp:425what's the right number here?
relevance 0../src/pread_disk_io.cpp:741back-pressure (the disk_observer o) is dropped on the blocked path. async_write returns false (keep writing) but the cache's back-pressure (driven off m_blocks) can't see the parked writes, so a long-lived fence (e.g. move_storage) on a busy torrent can grow m_blocked_jobs unbounded. Carry the observer through to throttle the peer while its writes are parked.
relevance 0../src/pread_disk_io.cpp:925we may not need to do this, the cache could tell us this piece should be flushed to disk now.
relevance 0../src/pread_disk_io.cpp:1361maybe we don't need to write to files we're about to delete
relevance 0../src/ip_notifier.cpp:18simulator support
relevance 0../src/enum_net.cpp:246if we get here, the caller still assumes the error code is reported via errno
relevance 0../src/enum_net.cpp:252if we get here, the caller still assumes the error code is reported via errno
relevance 0../src/ut_metadata.cpp:256we really need to increment the refcounter on the torrent while this buffer is still in the peer's send buffer
relevance 0../src/choker.cpp:235make configurable
relevance 0../src/pe_crypto.cpp:32it would be nice to get the literal working
relevance 0../src/pe_crypto.cpp:43it 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_handle.cpp:554support moving files into this call
relevance 0../src/torrent_handle.cpp:839deprecate the overload that takes an index
relevance 0../src/cpuid.cpp:114enable when aarch64 is really tested
relevance 0../src/file_storage.cpp:129at appears set_name is always true
relevance 0../src/file_storage.cpp:562maybe it would be nice to have a better index here
relevance 0../src/file_storage.cpp:1166do we still need this case?
relevance 0../src/file_storage.cpp:1307deprecated this. Do we need file_storage to support absolute paths?
relevance 0../src/file_storage.cpp:1421this would be more efficient if m_paths was sorted first, such that a lower path index always meant sorted-before
relevance 0../src/disabled_disk_io.cpp:83it would be nice to return a valid hash of zeroes here
relevance 0../src/kademlia/node_id.cpp:43it'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../src/kademlia/routing_table.cpp:264This 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:286arvidn 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:488this need to take bucket "prefix" into account. It should be unified with add_node_impl()
relevance 0../src/kademlia/node.cpp:1154keep the returned value to pass as a limit to write_nodes_entries when implemented
relevance 0../src/kademlia/node.cpp:1182limit number of entries in the result
relevance 0../src/kademlia/put_data.cpp:69what if o is not an instance of put_data_observer? This need to be redesigned for better type safety.
relevance 0../src/kademlia/item.cpp:120implement ctor for entry from bdecode_node?
relevance 0../src/kademlia/dht_tracker.cpp:293pick the closest node rather than the first
relevance 0../include/libtorrent/identify_client.hpp:23hide this declaration when deprecated functions are disabled, and remove its internal use
relevance 0../include/libtorrent/socket_type.hpp:39move to aux
relevance 0../include/libtorrent/performance_counters.hpp:520some space could be saved here by making gauges 32 bits
relevance 0../include/libtorrent/performance_counters.hpp:521restore these to regular integers. Instead have one copy of the counters per thread and collect them at convenient synchronization points
relevance 0../include/libtorrent/file_storage.hpp:705can we remove set_name?
relevance 0../include/libtorrent/i2p_stream.hpp:510make this a string_view
relevance 0../include/libtorrent/announce_entry.hpp:59include the number of peers received from this tracker, at last announce
relevance 0../include/libtorrent/peer_connection_interface.hpp:41make this interface smaller!
relevance 0../include/libtorrent/socks5_stream.hpp:176we could bind the socket here, since we know what the target endpoint is of the proxy
relevance 0../include/libtorrent/upnp.hpp:142support using the windows API for UPnP operations as well
relevance 0../include/libtorrent/kademlia/msg.hpp:64move this to its own .hpp/.cpp pair?
relevance 0../include/libtorrent/kademlia/item.hpp:38since 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_/piece_picker.hpp:808should this be allocated lazily?
relevance 0../include/libtorrent/aux_/piece_picker.hpp:880it would be more intuitive to account "wanted" pieces instead of filtered
relevance 0../include/libtorrent/aux_/session_impl.hpp:239make 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:1081replace this by a proper asio timer
relevance 0../include/libtorrent/aux_/session_impl.hpp:1086replace this by a proper asio timer
relevance 0../include/libtorrent/aux_/session_impl.hpp:1093replace this by a proper asio timer
relevance 0../include/libtorrent/aux_/session_interface.hpp:189it would be nice to not have this be part of session_interface
relevance 0../include/libtorrent/aux_/peer.hpp:47it seems unnecessary to wrap this i2p address in a struct
relevance 0../include/libtorrent/aux_/disk_cache.hpp:341it would be nice if this could be called without holding the mutex. It would require being able to lock the piece
relevance 0../include/libtorrent/aux_/disk_cache.hpp:368there may be a better way to solve this, maybe hang the job on the piece and try later. But it's a big change to do so
relevance 0../include/libtorrent/aux_/disk_io_thread_pool.hpp:30move into aux namespace
relevance 0../include/libtorrent/aux_/disk_io_thread_pool.hpp:106the job mutex must be held when this is called
relevance 0../include/libtorrent/aux_/disk_io_thread_pool.hpp:112the job mutex must be held when this is called
relevance 0../include/libtorrent/aux_/disk_io_thread_pool.hpp:118the job mutex must be held when this is called
relevance 0../include/libtorrent/aux_/disk_io_thread_pool.hpp:124the job mutex must be held when this is called
relevance 0../include/libtorrent/aux_/disk_io_thread_pool.hpp:130the job mutex must be held when this is called
relevance 0../include/libtorrent/aux_/disk_io_thread_pool.hpp:136the job mutex must be held when this is called
relevance 0../include/libtorrent/aux_/merkle_tree.hpp:62remove 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:152make this a std::unique_ptr
relevance 0../include/libtorrent/aux_/tracker_list.hpp:74make these iterators const
relevance 0../include/libtorrent/aux_/peer_connection.hpp:195make 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/aux_/peer_connection.hpp:1000factor this out into its own class with a virtual interface torrent and session should implement this interface
relevance 0../include/libtorrent/aux_/torrent.hpp:252make this a raw pointer. perhaps keep the shared_ptr around further down the object to maintain an owner
relevance 0../include/libtorrent/aux_/torrent.hpp:444make graceful pause also finish all sending blocks before disconnecting
relevance 0../include/libtorrent/aux_/torrent.hpp:1433this wastes 5 bits per file
relevance 0../include/libtorrent/aux_/torrent.hpp:1765this member can probably be removed
relevance 0../include/libtorrent/aux_/announce_entry.hpp:56include the number of peers received from this tracker, at last announce
relevance 0../include/libtorrent/aux_/store_buffer.hpp:84it would be nice if this could be called without holding the mutex. It would require a reference counter on the store buffer entries and that we potentially erases it after this call. it would also require the store buffer being able to take over ownership of the buffer when the owner erases it. Perhaps erase() could be made to take a buffer_holder, which is held onto if the refcount > 0
relevance 0../include/libtorrent/aux_/pool.hpp:27ensure the alignment is good here
relevance 0../include/libtorrent/aux_/proxy_base.hpp:204it 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/aux_/readwrite.hpp:255is it really necessary to make two copies of the iovecs? The low-level system call will need to make its own copy as well
relevance 0../include/libtorrent/aux_/deprecated.hpp:24figure out which version of clang this is supported in
relevance 0../include/libtorrent/aux_/utp_stream.hpp:667it would be nice to make this private
relevance 0../include/libtorrent/aux_/hash_picker.hpp:133support batched adding of block hashes for reduced overhead?
relevance 0../include/libtorrent/aux_/torrent_peer.hpp:228This destination should probably be kept in binary form (rather than base64). The peers should primarily be handled by their sha256 hash of the destination, that should be kept in here as well.