libtorrent todo-list

0 urgent 21 important 63 relevant 7 feasible 176 notes
relevance 3../src/file.cpp:541find out what error code is reported when the filesystem does not support hard links.
relevance 3../src/natpmp.cpp:557it would be nice to have a separate NAT-PMP error category
relevance 3../src/peer_connection.cpp:2968instead 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:3850once peers are properly put in graceful pause mode, they can cancel all outstanding requests and this test can be removed.
relevance 3../src/session_impl.cpp:3965it 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:3989peers 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:4266there should be a pre-calculated list of all peers eligible for unchoking
relevance 3../src/torrent.cpp:9698this really needs to be moved to do_async_save_resume_data. flags need to be passed on
relevance 3../src/upnp.cpp:94listen_interface is not used. It's meant to bind the broadcast socket. it would probably have to be changed to a vector of interfaces to bind to though, since the broadcast socket opens one socket per local interface by default
relevance 3../src/kademlia/node_id.cpp:54the XORing should be done at full words instead of bytes
relevance 3../src/kademlia/node_id.cpp:66the XORing should be done at full words instead of bytes
relevance 3../src/kademlia/node_id.cpp:82the xoring should be done at full words and _builtin_clz() could be used as the last step
relevance 3../src/kademlia/routing_table.cpp:688the call to compare_ip_cidr here is expensive. peel off some layers of abstraction here to make it quicker. Look at xoring and using _builtin_ctz()
relevance 3../src/kademlia/rpc_manager.cpp:87move this into it's own .cpp file
relevance 3../include/libtorrent/stat.hpp:263everything but payload counters and rates could probably be removed from here
relevance 3../include/libtorrent/torrent.hpp:1373factor out the links (as well as update_list() to a separate class that torrent can inherit)
relevance 3../include/libtorrent/torrent_handle.hpp:241consider replacing all the setters and getters for pause, resume, stop-when-ready, share-mode, upload-mode, super-seeding, apply-ip-filter, resolve-countries, pinned, sequential-download, seed-mode with just set_flags() and clear_flags() using the flags from add_torrent_params. Perhaps those flags should have a more generic name.
relevance 3../include/libtorrent/torrent_handle.hpp:488unify url_seed and http_seed with just web_seed, using the web_seed_entry.
relevance 3../include/libtorrent/web_peer_connection.hpp:131if 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/kademlia/routing_table.hpp:99to 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_/allocating_handler.hpp:77make sure the handlers we pass in are potentially movable!
relevance 2../test/test_dht.cpp:514split this test up into smaller test cases
relevance 2../test/test_dht.cpp:2141split this up into smaller test cases
relevance 2../test/test_piece_picker.cpp:281split this up into smaller tests (where we print_title)
relevance 2../test/test_storage.cpp:490split this test up into smaller parts
relevance 2../src/alert.cpp:1472the salt here is allocated on the heap. It would be nice to allocate in in the stack_allocator
relevance 2../src/alert_manager.cpp:90keep a count of the number of threads waiting. Only if it's > 0 notify them
relevance 2../src/block_cache.cpp:1715turn these return values into enums returns -1: block not in cache -2: out of memory
relevance 2../src/escape_string.cpp:209this should probably be moved into string_util.cpp
relevance 2../src/file.cpp:570test this on a FAT volume to see what error we get!
relevance 2../src/http_tracker_connection.cpp:381returning a bool here is redundant. Instead this function should return the peer_entry
relevance 2../src/instantiate_connection.cpp:43peer_connection and tracker_connection should probably be flags
relevance 2../src/instantiate_connection.cpp:44move this function into libtorrent::aux namespace
relevance 2../src/peer_connection.cpp:2386this 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:3132since 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:4819use a deadline_timer for timeouts. Don't rely on second_tick()! Hook this up to connect timeout as well. This would improve performance because of less work in second_tick(), and might let use remove ticking entirely eventually
relevance 2../src/peer_list.cpp:497it 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/piece_picker.cpp:1977make the 2048 limit configurable
relevance 2../src/piece_picker.cpp:2608the first_block returned here is the largest free range, not the first-fit range, which would be better
relevance 2../src/piece_picker.cpp:3386it 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 filed without also locking the piece? Perhaps write_failed() should imply locking it.
relevance 2../src/receive_buffer.cpp:209should this take a boost::array<..., 2> instead? it could return the number of buffers added, just like reserve.
relevance 2../src/session_impl.cpp:467is there a reason not to move all of this into init()? and just post it to the io_service?
relevance 2../src/session_impl.cpp:1989the udp socket(s) should be using the same generic mechanism and not be restricted to a single one we should open a one listen socket for each entry in the listen_interfaces list
relevance 2../src/session_impl.cpp:3742make 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:6289this should be factored into the udp socket, so we only have the code once
relevance 2../src/session_impl.cpp:6991perhaps DHT logging should be disabled by TORRENT_DISABLE_LOGGING too
relevance 2../src/storage.cpp:1116we probably need to do this unconditionally in this function. Even if the resume data file appears stale, we need to create these hard links, right?
relevance 2../src/storage.cpp:1140is 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/torrent.cpp:684post alert
relevance 2../src/torrent.cpp:1925add 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:4990abort lookups this torrent has made via the session host resolver interface
relevance 2../src/torrent.cpp:8192if 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/torrent.cpp:10655this should probably be removed
relevance 2../src/tracker_manager.cpp:200some of these arguments could probably be moved to the tracker request itself. like the ip_filter and settings
relevance 2../src/udp_socket.cpp:814the udp_socket should really just be a single socket, and the session should support having more than one, just like with TCP sockets for now, just make bind failures non-fatal
relevance 2../src/udp_tracker_connection.cpp:83support authentication here. tracker_req().auth
relevance 2../src/ut_metadata.cpp:123if we were to initialize m_metadata_size lazily instead, we would probably be more efficient initialize m_metadata_size
relevance 2../src/utp_socket_manager.cpp:244we may want to take ec into account here. possibly close connections quicker
relevance 2../src/utp_stream.cpp:386it would be nice if not everything would have to be public here
relevance 2../src/web_peer_connection.cpp:329do we really need a special case here? wouldn't the multi-file case handle single file torrents correctly too?
relevance 2../src/web_peer_connection.cpp:551just make this peer not have the pieces associated with the file we just requested. Only when it doesn't have any of the file do the following
relevance 2../src/web_peer_connection.cpp:603create a mapping of file-index to redirection URLs. Use that to form URLs instead. Support to reconnect to a new server without destructing this peer_connection
relevance 2../src/kademlia/dht_storage.cpp:110make this configurable in dht_settings
relevance 2../src/kademlia/node.cpp:658it would be nice to have a bias towards node-id prefixes that are missing in the bucket
relevance 2../src/kademlia/node.cpp:742use the non deprecated function instead of this one
relevance 2../src/kademlia/node.cpp:901find_node should write directly to the response entry
relevance 2../src/kademlia/routing_table.cpp:132use the non deprecated function instead of this one
relevance 2../src/kademlia/routing_table.cpp:982move the lowest priority nodes to the replacement bucket
relevance 2../include/libtorrent/alert_types.hpp:1443should the alert baseclass have this object instead?
relevance 2../include/libtorrent/broadcast_socket.hpp:53facto these functions out
relevance 2../include/libtorrent/build_config.hpp:40instead of using a dummy function to cause link errors when incompatible build configurations are used, make the namespace name depend on the configuration, and have a using declaration in the headers to pull it into libtorrent.
relevance 2../include/libtorrent/enum_net.hpp:151this could be done more efficiently by just looking up the interface with the given name, maybe even with if_nametoindex()
relevance 2../include/libtorrent/heterogeneous_queue.hpp:56add emplace_back() version
relevance 2../include/libtorrent/peer_connection.hpp:1118rename this target queue size
relevance 2../include/libtorrent/piece_picker.hpp:594having 8 priority levels is probably excessive. It should probably be changed to 3 levels + dont-download
relevance 2../include/libtorrent/proxy_base.hpp:260use the resolver interface that has a built-in cache
relevance 2../include/libtorrent/session_handle.hpp:78the ip filter should probably be saved here too
relevance 2../include/libtorrent/socks5_stream.hpp:191add async_connect() that takes a hostname and port as well
relevance 2../include/libtorrent/tracker_manager.hpp:293this class probably doesn't need to have virtual functions.
relevance 2../include/libtorrent/aux_/session_impl.hpp:1177the throttling of saving resume data could probably be factored out into a separate class
relevance 2../include/libtorrent/aux_/session_interface.hpp:128make 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:137the IP voting mechanism should be factored out to its own class, not part of the session
relevance 2../include/libtorrent/aux_/session_interface.hpp:162remove this. There's already get_resolver()
relevance 2../include/libtorrent/aux_/session_interface.hpp:217factor out the thread pool for socket jobs into a separate class used to (potentially) issue socket write calls onto multiple threads
relevance 1../src/disk_io_thread.cpp:211it would be nice to have the number of threads be set dynamically
relevance 1../src/http_seed_connection.cpp:129in chunked encoding mode, this assert won't hold. the chunk headers should be subtracted from the receive_buffer_size
relevance 1../src/session_impl.cpp:5658report the proper address of the router as the source IP of this understanding of our external address, instead of the empty address
relevance 1../src/torrent.cpp:1251make 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:7296save the send_stats state instead of throwing them away it may pose an issue when downgrading though
relevance 1../src/torrent.cpp:8537should disconnect all peers that have the pieces we have not just seeds. It would be pretty expensive to check all pieces for all peers though
relevance 1../include/libtorrent/ip_voter.hpp:124instead, have one instance per possible subnet, global IPv4, global IPv6, loopback, 192.168.x.x, 10.x.x.x, etc.
relevance 0../test/test_block_cache.cpp:469test try_evict_blocks
relevance 0../test/test_block_cache.cpp:470test evicting volatile pieces, to see them be removed
relevance 0../test/test_block_cache.cpp:471test evicting dirty pieces
relevance 0../test/test_block_cache.cpp:472test free_piece
relevance 0../test/test_block_cache.cpp:473test abort_dirty
relevance 0../test/test_block_cache.cpp:474test unaligned reads
relevance 0../test/test_bloom_filter.cpp:130test size()
relevance 0../test/test_bloom_filter.cpp:131test clear()
relevance 0../test/test_dht.cpp:103ideally the mock_socket would contain this queue of packets, to make tests independent
relevance 0../test/test_dht.cpp:420check to make sure the "best" items are stored
relevance 0../test/test_dht.cpp:513test obfuscated_get_peers
relevance 0../test/test_fast_extension.cpp:1020test sending invalid requests (out of bound piece index, offsets and sizes)
relevance 0../test/test_file_progress.cpp:109test the update function too
relevance 0../test/test_file_storage.cpp:277add more optimize() tests
relevance 0../test/test_file_storage.cpp:278test map_block
relevance 0../test/test_file_storage.cpp:279test piece_size(int piece)
relevance 0../test/test_file_storage.cpp:280test file_index_at_offset
relevance 0../test/test_file_storage.cpp:281test file attributes
relevance 0../test/test_file_storage.cpp:282test symlinks
relevance 0../test/test_file_storage.cpp:283test pad_files
relevance 0../test/test_file_storage.cpp:284test reorder_file (make sure internal_file_entry::swap() is used)
relevance 0../test/test_peer_list.cpp:939test erasing peers
relevance 0../test/test_peer_list.cpp:940test update_peer_port with allow_multiple_connections_per_ip and without
relevance 0../test/test_peer_list.cpp:941test add i2p peers
relevance 0../test/test_peer_list.cpp:942test allow_i2p_mixed
relevance 0../test/test_peer_list.cpp:943test insert_peer failing with all error conditions
relevance 0../test/test_peer_list.cpp:944test IPv6
relevance 0../test/test_peer_list.cpp:945test connect_to_peer() failing
relevance 0../test/test_peer_list.cpp:946test connection_closed
relevance 0../test/test_peer_list.cpp:947connect candidates recalculation when incrementing failcount
relevance 0../test/test_resolve_links.cpp:80test files with different piece size (negative test)
relevance 0../test/test_resolve_links.cpp:83it 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_resume.cpp:292test what happens when loading a resume file with both piece priorities and file priorities (file prio should take presedence)
relevance 0../test/test_resume.cpp:295make sure a resume file only ever contain file priorities OR piece priorities. Never both.
relevance 0../test/test_resume.cpp:298generally save
relevance 0../test/test_resume.cpp:755test 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_settings_pack.cpp:227load_pack_from_dict
relevance 0../test/test_ssl.cpp:394test using a signed certificate with the wrong info-hash in DN
relevance 0../test/test_ssl.cpp:492also 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_torrent_info.cpp:166test remap_files
relevance 0../test/test_torrent_info.cpp:167merkle torrents. specifically torrent_info::add_merkle_nodes and torrent with "root hash"
relevance 0../test/test_torrent_info.cpp:168torrent with 'p' (padfile) attribute
relevance 0../test/test_torrent_info.cpp:169torrent with 'h' (hidden) attribute
relevance 0../test/test_torrent_info.cpp:170torrent with 'x' (executable) attribute
relevance 0../test/test_torrent_info.cpp:171torrent with 'l' (symlink) attribute
relevance 0../test/test_torrent_info.cpp:172creating a merkle torrent (torrent_info::build_merkle_list)
relevance 0../test/test_torrent_info.cpp:173torrent 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:174torrents with a zero-length name
relevance 0../test/test_torrent_info.cpp:175torrents with a merkle tree and add_merkle_nodes
relevance 0../test/test_torrent_info.cpp:176torrent with a non-dictionary info-section
relevance 0../test/test_torrent_info.cpp:177torrents with DHT nodes
relevance 0../test/test_torrent_info.cpp:178torrent with url-list as a single string
relevance 0../test/test_torrent_info.cpp:179torrent with http seed as a single string
relevance 0../test/test_torrent_info.cpp:180torrent with a comment
relevance 0../test/test_torrent_info.cpp:181torrent with an SSL cert
relevance 0../test/test_torrent_info.cpp:182torrent with attributes (executable and hidden)
relevance 0../test/test_torrent_info.cpp:183torrent_info::add_tracker
relevance 0../test/test_torrent_info.cpp:184torrent_info::unload
relevance 0../test/test_torrent_info.cpp:185torrent_info constructor that takes an invalid bencoded buffer
relevance 0../test/test_torrent_info.cpp:186verify_encoding with a string that triggers character replacement
relevance 0../test/test_tracker.cpp:53test scrape requests
relevance 0../test/test_tracker.cpp:54test parse peers6
relevance 0../test/test_tracker.cpp:55test parse tracker-id
relevance 0../test/test_tracker.cpp:56test parse failure-reason
relevance 0../test/test_tracker.cpp:57test 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_transfer.cpp:211these settings_pack tests belong in their own test
relevance 0../test/test_transfer.cpp:290factor out the disk-full test into its own unit test
relevance 0../test/test_upnp.cpp:108store the log and verify that some key messages are there
relevance 0../src/block_cache.cpp:1040it's somewhat expensive to iterate over this linked list. Presumably because of the random access of memory. It would be nice if pieces with no evictable blocks weren't in this list
relevance 0../src/block_cache.cpp:1111this should probably only be done every n:th time
relevance 0../src/block_cache.cpp:1803create a holder for refcounts that automatically decrement
relevance 0../src/bt_peer_connection.cpp:700this could be optimized using knuth morris pratt
relevance 0../src/bt_peer_connection.cpp:2254if we're finished, send upload_only message
relevance 0../src/choker.cpp:353optimize this using partial_sort or something. We don't need to sort the entire list
relevance 0../src/choker.cpp:356make the comparison function a free function and move it into this cpp file
relevance 0../src/choker.cpp:361make configurable
relevance 0../src/choker.cpp:375make configurable
relevance 0../src/create_torrent.cpp:294this should probably be optional
relevance 0../src/disk_buffer_pool.cpp:257perhaps we should sort the buffers here?
relevance 0../src/disk_io_thread.cpp:881it would be nice to optimize this by having the cache pieces also ordered by
relevance 0../src/disk_io_thread.cpp:924instead of doing a lookup each time through the loop, save cached_piece_entry pointers with piece_refcount incremented to pin them
relevance 0../src/disk_io_thread.cpp:1113instead of doing this. pass in the settings to each storage_interface call. Each disk thread could hold its most recent understanding of the settings in a shared_ptr, and update it every time it wakes up from a job. That way each access to the settings won't require a mutex to be held.
relevance 0../src/disk_io_thread.cpp:1158a potentially more efficient solution would be to have a special queue for retry jobs, that's only ever run when a job completes, in any thread. It would only work if counters::num_running_disk_jobs > 0
relevance 0../src/disk_io_thread.cpp:1829maybe the tailqueue_iterator should contain a pointer-pointer instead and have an unlink function
relevance 0../src/disk_io_thread.cpp:2095this is potentially very expensive. One way to solve it would be to have a fence for just this one piece.
relevance 0../src/disk_io_thread.cpp:2359we should probably just hang the job on the piece and make sure the hasher gets kicked
relevance 0../src/disk_io_thread.cpp:2435introduce a holder class that automatically increments and decrements the piece_refcount
relevance 0../src/disk_io_thread.cpp:2687it would be nice to not have to lock the mutex every turn through this loop
relevance 0../src/enum_net.cpp:287get the MTU (and other interesting metrics) from the rt_msghdr instead
relevance 0../src/file_progress.cpp:160it would be nice to not depend on alert_manager here
relevance 0../src/metadata_transfer.cpp:365this is not safe. The torrent could be unloaded while we're still sending the metadata
relevance 0../src/packet_buffer.cpp:180use compare_less_wrap for this comparison as well
relevance 0../src/part_file.cpp:252what do we do if someone is currently reading from the disk from this piece? does it matter? Since we won't actively erase the data from disk, but it may be overwritten soon, it's probably not that big of a deal
relevance 0../src/part_file.cpp:375instead of rebuilding the whole file header and flushing it, update the slot entries as we go
relevance 0../src/peer_connection.cpp:526it would be neat to be able to print this straight into the alert's stack allocator
relevance 0../src/peer_connection.cpp:1037this should be the global download rate
relevance 0../src/peer_connection.cpp:3380sort the allowed fast set in priority order
relevance 0../src/peer_connection.cpp:6202The stats checks can not be honored when authenticated encryption is in use because we may have encrypted data which we cannot authenticate yet
relevance 0../src/piece_picker.cpp:2056this 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:2578when expanding pieces for cache stripe reasons, the !downloading condition doesn't make much sense
relevance 0../src/session_impl.cpp:527there's no rule here to make uTP connections not have the global or local rate limits apply to it. This used to be the default.
relevance 0../src/session_impl.cpp:1667it would be nice to reserve() these vectors up front
relevance 0../src/session_impl.cpp:1905instead of having a special case for this, just make the default listen interfaces be "0.0.0.0:6881,[::]:6881" and use the generic path. That would even allow for not listening at all.
relevance 0../src/session_impl.cpp:2932should this function take a shared_ptr instead?
relevance 0../src/session_impl.cpp:3326have a separate list for these connections, instead of having to loop through all of them
relevance 0../src/session_impl.cpp:3359this should apply to all bandwidth channels
relevance 0../src/session_impl.cpp:4150use 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:4302post a message to have this happen immediately instead of waiting for the next tick
relevance 0../src/session_impl.cpp:4690it 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:5043this logic could probably be less spaghetti looking by being moved to a function with early exits
relevance 0../src/session_impl.cpp:5622perhaps this function should not exist when logging is disabled
relevance 0../src/settings_pack.cpp:582it would be nice to reserve() these vectors up front
relevance 0../src/storage.cpp:934make this more generic to not just work if files have been renamed, but also if they have been merged into a single file for instance maybe use the same format as .torrent files and reuse some code from torrent_info
relevance 0../src/storage.cpp:1242ideally, 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/string_util.cpp:60warning C4146: unary minus operator applied to unsigned type, result still unsigned
relevance 0../src/torrent.cpp:102factor out cache_status to its own header
relevance 0../src/torrent.cpp:471if the existing torrent doesn't have metadata, insert the metadata we just downloaded into it.
relevance 0../src/torrent.cpp:583if the existing torrent doesn't have metadata, insert the metadata we just downloaded into it.
relevance 0../src/torrent.cpp:1581is verify_peer_cert called once per certificate in the chain, and this function just tells us which depth we're at right now? If so, the comment makes sense. any certificate that isn't the leaf (i.e. the one presented by the peer) should be accepted automatically, given preverified is true. The leaf certificate need to be verified to make sure its DN matches the info-hash
relevance 0../src/torrent.cpp:2003instead of creating the picker up front here, maybe this whole section should move to need_picker()
relevance 0../src/torrent.cpp:2077this could be optimized by looking up which files are complete and just look at those
relevance 0../src/torrent.cpp:2093this could be optimized by looking up which files are complete and just look at those
relevance 0../src/torrent.cpp:2259there may be peer extensions relying on the torrent extension still being alive. Only do this if there are no peers. And when the last peer is disconnected, if the torrent is unloaded, clear the extensions m_extensions.clear();
relevance 0../src/torrent.cpp:2964this 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:3824add one peer per IP the hostname resolves to
relevance 0../src/torrent.cpp:4766update suggest_piece?
relevance 0../src/torrent.cpp:4910really, we should just keep the picker around in this case to maintain the availability counters
relevance 0../src/torrent.cpp:6986make this more generic to not just work if files have been renamed, but also if they have been merged into a single file for instance maybe use the same format as .torrent files and reuse some code from torrent_info The mapped_files needs to be read both in the network thread and in the disk thread, since they both have their own mapped files structures which are kept in sync
relevance 0../src/torrent.cpp:7119if this is a merkle torrent and we can't restore the tree, we need to wipe all the bits in the have array, but not necessarily we might want to do a full check to see if we have all the pieces. This is low priority since almost no one uses merkle torrents
relevance 0../src/torrent.cpp:7220re-enable this code once there's a non-inlined encoder function. Or perhaps this should not be used until saving resume_data via add_torrent_params and a free function, similar to read_resume_data boost::shared_array const info = torrent_file().metadata(); int const size = torrent_file().metadata_size(); ret["info"].preformatted().assign(&info[0], &info[0] + size);
relevance 0../src/torrent.cpp:7369make this more generic to not just work if files have been renamed, but also if they have been merged into a single file for instance. using file_base
relevance 0../src/torrent.cpp:9646add a flag to ignore stats, and only care about resume data for content. For unchanged files, don't trigger a load of the metadata just to save an empty resume data file
relevance 0../src/torrent.cpp:11296instead of resorting the whole list, insert the peers directly into the right place
relevance 0../src/torrent_peer.cpp:188how do we deal with our external address changing?
relevance 0../src/udp_socket.cpp:329it would be nice to detect this on posix systems also
relevance 0../src/udp_socket.cpp:881use the system resolver_interface here
relevance 0../src/ut_metadata.cpp:320we really need to increment the refcounter on the torrent while this buffer is still in the peer's send buffer
relevance 0../src/utp_stream.cpp:1769this loop is not very efficient. It could be fixed by having a separate list of sequence numbers that need resending
relevance 0../src/web_connection_base.cpp:81introduce a web-seed default class which has a low download priority
relevance 0../src/kademlia/dht_storage.cpp:447c++11 use a lambda here instead
relevance 0../src/kademlia/node.cpp:723in the future, this function should update all the dht related counter. For now, it just update the storage related ones.
relevance 0../src/kademlia/put_data.cpp:93what if o is not an isntance of put_data_observer? This need to be redesigned for better type saftey.
relevance 0../include/libtorrent/alert_types.hpp:171Once the backwards compatibility of clone() is removed, and once C++11 is required, this can be simplified to just say = delete
relevance 0../include/libtorrent/announce_entry.hpp:97include the number of peers received from this tracker, at last announce
relevance 0../include/libtorrent/block_cache.hpp:223make this 32 bits and to count seconds since the block cache was created
relevance 0../include/libtorrent/config.hpp:359Make this count Unicode characters instead of bytes on windows
relevance 0../include/libtorrent/file.hpp:175move this into a separate header file, TU pair
relevance 0../include/libtorrent/heterogeneous_queue.hpp:184if this throws, should we do anything?
relevance 0../include/libtorrent/identify_client.hpp:47hide this declaration when deprecated functions are disabled, and remove its internal use
relevance 0../include/libtorrent/peer_connection.hpp:209make 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:1046factor this out into its own class with a virtual interface torrent and session should implement this interface
relevance 0../include/libtorrent/peer_connection_interface.hpp:47make this interface smaller!
relevance 0../include/libtorrent/performance_counters.hpp:139should keepalives be in here too? how about dont-have, share-mode, upload-only
relevance 0../include/libtorrent/performance_counters.hpp:450some space could be saved here by making gauges 32 bits
relevance 0../include/libtorrent/performance_counters.hpp:451restore these to regular integers. Instead have one copy of the counters per thread and collect them at convenient synchronization points
relevance 0../include/libtorrent/piece_picker.hpp:756should this be allocated lazily?
relevance 0../include/libtorrent/proxy_base.hpp:174it 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/receive_buffer.hpp:272Detect when the start of the next crpyto packet is aligned with the start of piece data and the crpyto packet is at least as large as the piece data. With a little extra work we could receive directly into a disk buffer in that case.
relevance 0../include/libtorrent/session_handle.hpp:665add get_peer_class_type_filter() as well
relevance 0../include/libtorrent/settings_pack.hpp:1141deprecate this ``max_rejects`` is the number of piece requests we will reject in a row while a peer is choked before the peer is considered abusive and is disconnected.
relevance 0../include/libtorrent/torrent.hpp:195make this a raw pointer. perhaps keep the shared_ptr around further down the object to maintain an owner
relevance 0../include/libtorrent/torrent.hpp:1270this wastes 5 bits per file
relevance 0../include/libtorrent/torrent.hpp:1328These two bitfields should probably be coalesced into one
relevance 0../include/libtorrent/torrent_info.hpp:117there may be some opportunities to optimize the size if torrent_info. specifically to turn some std::string and std::vector into pointers
relevance 0../include/libtorrent/tracker_manager.hpp:395this should be unique_ptr in the future
relevance 0../include/libtorrent/upnp.hpp:157support using the windows API for UPnP operations as well
relevance 0../include/libtorrent/utp_stream.hpp:424implement blocking write. Low priority since it's not used (yet)
relevance 0../include/libtorrent/kademlia/item.hpp:61since this is a public function, it should probably be moved out of this header and into one with other public functions.
relevance 0../include/libtorrent/aux_/session_impl.hpp:868should this be renamed m_outgoing_interfaces?
relevance 0../include/libtorrent/aux_/session_impl.hpp:920replace this by a proper asio timer
relevance 0../include/libtorrent/aux_/session_impl.hpp:925replace this by a proper asio timer
relevance 0../include/libtorrent/aux_/session_impl.hpp:932replace this by a proper asio timer
relevance 0../include/libtorrent/aux_/session_interface.hpp:241it would be nice to not have this be part of session_interface
relevance 0../include/libtorrent/aux_/session_settings.hpp:78make this a bitfield