libtorrent todo-list

2 urgent 39 important 50 relevant 4 feasible 190 notes
relevance 4../test/test_dht.cpp:1266pass in the actual salt as a parameter
relevance 4../test/test_dht.cpp:2154pass 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:1223split this up into smaller tests
relevance 3../test/test_dht.cpp:2623use dht_test_setup class to simplify the node setup
relevance 3../test/test_dht.cpp:3168use dht_test_setup class to simplify the node setup
relevance 3../test/test_dht.cpp:3313use dht_test_setup class to simplify the node setup
relevance 3../test/test_dht.cpp:3406use dht_test_setup class to simplify the node setup
relevance 3../src/web_peer_connection.cpp:200this should be an optional, piece index -1 should not be allowed
relevance 3../src/web_peer_connection.cpp:420do 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:514file_index_t should not allow negative values
relevance 3../src/web_peer_connection.cpp:710this 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:268use the aux::write_* functions and the span here instead, it will fit better with send_buffer()
relevance 3../src/torrent.cpp:461we could probably get away with just saving a few fields here
relevance 3../src/torrent.cpp:766assert there are no outstanding async operations on this torrent
relevance 3../src/torrent.cpp:1401there's some duplication between this function and peer_connection::incoming_piece(). is there a way to merge something?
relevance 3../src/torrent.cpp:4073this could probably be pulled out into a free function
relevance 3../src/torrent.cpp:5051should this alert have an error code in it?
relevance 3../src/torrent.cpp:5110this should return optional<>. piece index -1 should not be allowed
relevance 3../src/session_impl.cpp:1152closing the udp sockets here means that the uTP connections cannot be closed gracefully
relevance 3../src/session_impl.cpp:1654the logic in this if-block should be factored out into a separate function. At least most of it
relevance 3../src/session_impl.cpp:2624it would be neat if the utp socket manager would handle ICMP errors too
relevance 3../src/session_impl.cpp:4173it 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:4196peers 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:4442there should be a pre-calculated list of all peers eligible for unchoking
relevance 3../src/session_impl.cpp:6173use public_key here instead of std::array
relevance 3../src/session_handle.cpp:695expose the sequence_number, public_key, secret_key and signature types to the client
relevance 3../src/peer_connection.cpp:3147instead 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:4038once 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:4715new_piece should be an optional. piece index -1 should not be allowed
relevance 3../src/kademlia/rpc_manager.cpp:71move this into it's own .cpp 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:548unify url_seed and http_seed with just web_seed, using the web_seed_entry.
relevance 3../include/libtorrent/torrent.hpp:1483factor out predictive pieces and all operations on it into a separate class (to use as member here instead)
relevance 3../include/libtorrent/torrent.hpp:1543factor out the links (as well as update_list() to a separate class that torrent can inherit)
relevance 3../include/libtorrent/stat.hpp:257everything but payload counters and rates could probably be removed from here
relevance 3../include/libtorrent/pe_crypto.hpp:72dh_key_exchange should probably move into its own file
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_storage.cpp:813split this test up into smaller parts
relevance 2../test/test_piece_picker.cpp:2997test picking with partial pieces and other peers present so that both backup_pieces and backup_pieces2 are used
relevance 2../test/test_dht.cpp:1658test num_global_nodes
relevance 2../test/test_dht.cpp:1659test need_refresh
relevance 2../test/test_dht.cpp:2844split this up into smaller test cases
relevance 2../src/web_peer_connection.cpp:636just 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/upnp.cpp:116use boost::asio::ip::network instead of netmask
relevance 2../src/udp_tracker_connection.cpp:81support authentication here. tracker_req().auth
relevance 2../src/tracker_manager.cpp:389implement
relevance 2../src/torrent.cpp:551post alert
relevance 2../src/torrent.cpp:1938add 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:4620use chrono type for time duration
relevance 2../src/torrent.cpp:5065abort lookups this torrent has made via the session host resolver interface
relevance 2../src/torrent.cpp:8190if 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/storage_utils.cpp:295technically, 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:487is 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/session_impl.cpp:599is 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:775the ip filter should probably be saved here too
relevance 2../src/session_impl.cpp:3900make 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:5540this 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:5580this 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:6427this should be factored into the udp socket, so we only have the code once
relevance 2../src/piece_picker.cpp:2013make the 2048 limit configurable
relevance 2../src/piece_picker.cpp:2611the first_block returned here is the largest free range, not the first-fit range, which would be better
relevance 2../src/piece_picker.cpp:3495it 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/peer_list.cpp:535it 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/peer_connection.cpp:2571this 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:3323since 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:4961use 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/path.cpp:436test this on a FAT volume to see what error we get!
relevance 2../src/instantiate_connection.cpp:44peer_connection and tracker_connection should probably be flags
relevance 2../src/http_tracker_connection.cpp:486returning a bool here is redundant. Instead this function should return the peer_entry
relevance 2../src/escape_string.cpp:193this should probably be moved into string_util.cpp
relevance 2../src/bdecode.cpp:827attempt to simplify this implementation by embracing the span
relevance 2../src/alert_manager.cpp:76keep a count of the number of threads waiting. Only if it's > 0 notify them
relevance 2../src/alert.cpp:2004the salt here is allocated on the heap. It would be nice to allocate in the stack_allocator
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../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../include/libtorrent/socks5_stream.hpp:155add async_connect() that takes a hostname and port as well
relevance 2../include/libtorrent/proxy_base.hpp:328use the resolver interface that has a built-in cache
relevance 2../include/libtorrent/piece_picker.hpp:668having 8 priority levels is probably excessive. It should probably be changed to 3 levels + dont-download
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/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:59this type should probably be renamed to send_buffer
relevance 1../src/torrent.cpp:1179make 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:8562should 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:5741report 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_upnp.cpp:156store the log and verify that some key messages are there
relevance 0../test/test_transfer.cpp:173these settings_pack tests belong in their own test
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_torrent_info.cpp:475test remap_files
relevance 0../test/test_torrent_info.cpp:476torrent with 'p' (padfile) attribute
relevance 0../test/test_torrent_info.cpp:477torrent with 'h' (hidden) attribute
relevance 0../test/test_torrent_info.cpp:478torrent with 'x' (executable) attribute
relevance 0../test/test_torrent_info.cpp:479torrent with 'l' (symlink) attribute
relevance 0../test/test_torrent_info.cpp:480torrent 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:483torrents with a zero-length name
relevance 0../test/test_torrent_info.cpp:484torrent with a non-dictionary info-section
relevance 0../test/test_torrent_info.cpp:485torrents with DHT nodes
relevance 0../test/test_torrent_info.cpp:486torrent with url-list as a single string
relevance 0../test/test_torrent_info.cpp:487torrent with http seed as a single string
relevance 0../test/test_torrent_info.cpp:488torrent with a comment
relevance 0../test/test_torrent_info.cpp:489torrent with an SSL cert
relevance 0../test/test_torrent_info.cpp:490torrent with attributes (executable and hidden)
relevance 0../test/test_torrent_info.cpp:491torrent_info constructor that takes an invalid bencoded buffer
relevance 0../test/test_torrent_info.cpp:492verify_encoding with a string that triggers character replacement
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_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_resume.cpp:614test 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:617make sure a resume file only ever contain file priorities OR piece priorities. Never both.
relevance 0../test/test_resume.cpp:620generally save
relevance 0../test/test_resume.cpp:943test 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:1715test 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_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_peer_list.cpp:1291test erasing peers
relevance 0../test/test_peer_list.cpp:1292test update_peer_port with allow_multiple_connections_per_ip and without
relevance 0../test/test_peer_list.cpp:1293test add i2p peers
relevance 0../test/test_peer_list.cpp:1294test allow_i2p_mixed
relevance 0../test/test_peer_list.cpp:1295test insert_peer failing with all error conditions
relevance 0../test/test_peer_list.cpp:1296test IPv6
relevance 0../test/test_peer_list.cpp:1297test connect_to_peer() failing
relevance 0../test/test_peer_list.cpp:1298test connection_closed
relevance 0../test/test_peer_list.cpp:1299connect candidates recalculation when incrementing failcount
relevance 0../test/test_merkle_tree.cpp:233use structured bindings in C++17
relevance 0../test/test_merkle_tree.cpp:995add test for load_piece_layer()
relevance 0../test/test_merkle_tree.cpp:996add test for add_hashes() with an odd number of blocks
relevance 0../test/test_merkle_tree.cpp:997add test for set_block() (setting the last block) with an odd number of blocks
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_file_storage.cpp:1235test file attributes
relevance 0../test/test_file_storage.cpp:1236test symlinks
relevance 0../test/test_fast_extension.cpp:1228test sending invalid requests (out of bound piece index, offsets and sizes)
relevance 0../test/test_dht.cpp:488check to make sure the "best" items are stored
relevance 0../test/test_dht.cpp:3239this 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:4150test obfuscated_get_peers
relevance 0../test/test_bloom_filter.cpp:135test size()
relevance 0../test/test_bloom_filter.cpp:136test clear()
relevance 0../src/web_connection_base.cpp:73introduce a web-seed default class which has a low download priority
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/udp_tracker_connection.cpp:633why is this a linked list?
relevance 0../src/udp_socket.cpp:670perhaps an attempt should be made to bind m_socks5_sock to the device of m_listen_socket
relevance 0../src/torrent_peer.cpp:193how do we deal with our external address changing?
relevance 0../src/torrent_info.cpp:901this should be considered a failure, and the .torrent file rejected
relevance 0../src/torrent_handle.cpp:604support moving files into this call
relevance 0../src/torrent.cpp:2037this could be optimized by looking up which files are complete and just look at those
relevance 0../src/torrent.cpp:2050this could be optimized by looking up which files are complete and just look at those
relevance 0../src/torrent.cpp:2818this 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:3992add one peer per IP the hostname resolves to
relevance 0../src/torrent.cpp:4709only 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:7665come up with a better way of doing this, instead of an immediately invoked lambda expression.
relevance 0../src/torrent.cpp:9311perhaps 0 should actually mean 0
relevance 0../src/torrent.cpp:9328perhaps 0 should actually mean 0
relevance 0../src/torrent.cpp:11270instead of resorting the whole list, insert the peers directly into the right place
relevance 0../src/storage_utils.cpp:231ideally, 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:539it 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/smart_ban.cpp:178replace with std::erase_if() once we require C++20
relevance 0../src/settings_pack.cpp:309deprecate this
relevance 0../src/settings_pack.cpp:597it would be nice to reserve() these vectors up front
relevance 0../src/session_impl.cpp:615come 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:1500it would be nice to reserve() these vectors up front
relevance 0../src/session_impl.cpp:2014could 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:2322it 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:2884this size need to be capped
relevance 0../src/session_impl.cpp:2909this size need to be capped
relevance 0../src/session_impl.cpp:3608have a separate list for these connections, instead of having to loop through all of them
relevance 0../src/session_impl.cpp:3641this should apply to all bandwidth channels
relevance 0../src/session_impl.cpp:4332use 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:4477post a message to have this happen immediately instead of waiting for the next tick
relevance 0../src/session_impl.cpp:4804it 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:5186factor out this logic into a separate function for unit testing
relevance 0../src/session_impl.cpp:5917refactor, move the storage to dht_tracker
relevance 0../src/session_impl.cpp:6304asserts that no outstanding async operations are still in flight
relevance 0../src/session_handle.cpp:503in C++14, use unique_ptr and move it into the lambda
relevance 0../src/session.cpp:540In C++17. use if constexpr instead
relevance 0../src/random.cpp:141improve calling RAND_bytes multiple times, using fallback for now
relevance 0../src/posix_part_file.cpp:339what 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:429instead of rebuilding the whole file header and flushing it, update the slot entries as we go
relevance 0../src/piece_picker.cpp:121find a better place for this
relevance 0../src/piece_picker.cpp:2084this 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:2228Is it a good idea that this affinity takes precedence over piece priority?
relevance 0../src/piece_picker.cpp:2583when expanding pieces for cache stripe reasons, the !downloading condition doesn't make much sense
relevance 0../src/piece_picker.cpp:3161should 5 be configurable?
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/peer_connection.cpp:1108this should be the global download rate
relevance 0../src/peer_connection.cpp:3550sort the allowed fast set in priority order
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/part_file.cpp:302what 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/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 altogether
relevance 0../src/merkle_tree.cpp:110in C++20, use std::identity
relevance 0../src/merkle_tree.cpp:329this 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:377a 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:457instead 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:481this could be done more efficiently if bitfield had a function to set a range of bits
relevance 0../src/merkle_tree.cpp:524use structured binding in C++17
relevance 0../src/merkle_tree.cpp:549this could be done more efficiently if bitfield had a function to set a range of bits
relevance 0../src/magnet_uri.cpp:451what's the right number here?
relevance 0../src/load_torrent.cpp:121move the loading logic from torrent_info constructor into here
relevance 0../src/ip_notifier.cpp:41simulator support
relevance 0../src/http_seed_connection.cpp:437technically, this isn't supposed to happen, but it seems to sometimes. Some of the accounting is probably wrong in certain cases
relevance 0../src/hash_picker.cpp:335use structured bindings in C++17
relevance 0../src/file_storage.cpp:458maybe it would be nice to have a better index here
relevance 0../src/file_storage.cpp:1243this would be more efficient if m_paths was sorted first, such that a lower path index always meant sorted-before
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/disabled_disk_io.cpp:106it would be nice to return a valid hash of zeroes here
relevance 0../src/create_torrent.cpp:645this can be optimized
relevance 0../src/cpuid.cpp:131enable when aarch64 is really tested
relevance 0../src/choker.cpp:258make configurable
relevance 0../src/alert.cpp:387move this field into tracker_alert
relevance 0../src/alert.cpp:421move this into tracker_alert
relevance 0../src/alert.cpp:447move this into tracker_alert
relevance 0../src/alert.cpp:476move this into tracker_alert
relevance 0../src/alert.cpp:515move this field into tracker_alert
relevance 0../src/alert.cpp:559move this to tracker_alert
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/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/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/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../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../include/libtorrent/upnp.hpp:164support using the windows API for UPnP operations as well
relevance 0../include/libtorrent/torrent_info.hpp:758change 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/torrent.hpp:311make this a raw pointer. perhaps keep the shared_ptr around further down the object to maintain an owner
relevance 0../include/libtorrent/torrent.hpp:494make graceful pause also finish all sending blocks before disconnecting
relevance 0../include/libtorrent/torrent.hpp:631make this flag a combination of the other ones
relevance 0../include/libtorrent/torrent.hpp:1440this wastes 5 bits per file
relevance 0../include/libtorrent/torrent.hpp:1737this member can probably be removed
relevance 0../include/libtorrent/string_view.hpp:40replace this by the standard string_view in C++17
relevance 0../include/libtorrent/socks5_stream.hpp:199we could bind the socket here, since we know what the target endpoint is of the proxy
relevance 0../include/libtorrent/socket_type.hpp:60move to aux
relevance 0../include/libtorrent/proxy_base.hpp:227it 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/piece_picker.hpp:823should this be allocated lazily?
relevance 0../include/libtorrent/piece_picker.hpp:895it would be more intuitive to account "wanted" pieces instead of filtered
relevance 0../include/libtorrent/performance_counters.hpp:491some space could be saved here by making gauges 32 bits
relevance 0../include/libtorrent/performance_counters.hpp:492restore these to regular integers. Instead have one copy of the counters per thread and collect them at convenient synchronization points
relevance 0../include/libtorrent/peer_connection_interface.hpp:51make this interface smaller!
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/i2p_stream.hpp:585make this a string_view
relevance 0../include/libtorrent/hash_picker.hpp:155support batched adding of block hashes for reduced overhead?
relevance 0../include/libtorrent/announce_entry.hpp:76include the number of peers received from this tracker, at last announce
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_/utp_stream.hpp:693it would be nice to make this private
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_/session_impl.hpp:265make 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:1090replace this by a proper asio timer
relevance 0../include/libtorrent/aux_/session_impl.hpp:1095replace this by a proper asio timer
relevance 0../include/libtorrent/aux_/session_impl.hpp:1102replace this by a proper asio timer
relevance 0../include/libtorrent/aux_/pool.hpp:53ensure the alignment is good here
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_/deprecated.hpp:47figure out which version of clang this is supported in
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_/allocating_handler.hpp:316in C++17, Handler and Storage could just use "auto"