libtorrent todo-list

2 urgent 15 important 19 relevant 9 feasible 86 notes
relevance 4../src/session_impl.cpp:480in order to support SSL over uTP, the utp_socket manager either needs to be able to receive packets on multiple ports, or we need to peek into the first few bytes the payload stream of a socket to determine whether or not it's an SSL connection. (The former is simpler but won't do as well with NATs)
relevance 4../src/kademlia/refresh.cpp:93when bootstrapping against our own IP completes, continue to issue another bootstrap against the deepest, non-full bucket. when it completes, issue a bootstrap against one bucket above it, and so on until the bootstrap lookup against the top level bucket (bucket 0) completes. That's when the bootstrap is done
relevance 3../src/disk_io_thread.cpp:242it would be nice to have the number of threads be set dynamically
relevance 3../src/peer_connection.cpp:1713we should probably use ses.m_allowed_upload_slots here instead to work with auto-unchoke logic
relevance 3../src/peer_connection.cpp:3043since we throw away the queue entry once we issue the disk job, this may happen. Instead, we should keep the queue entry around, mark it as having been requested from disk and once the disk job comes back, discard it if it has been cancelled. Maybe even be able to cancel disk jobs?
relevance 3../src/peer_connection.cpp:4740instead of using settings_pack::request_timeout, use m_rtt.mean() + m_rtt.avg_deviation() * 2 or something like that. the configuration option could hopefully be removed
relevance 3../src/piece_picker.cpp:3166it 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
relevance 3../src/resolver.cpp:39the first places to use this resolver is the http_connection/http_tracker_connection and udp_tracker_connection. make sure to prefer cache on shutdown
relevance 3../src/session_impl.cpp:5700it would be really nice to update these counters as they are incremented. This depends on the session being ticked, which has a fairly coarse grained resolution
relevance 3../src/session_impl.cpp:7152If socket jobs could be higher level, to include RC4 encryption and decryption, we would offload the main thread even more
relevance 3../src/torrent.cpp:1081if any other peer has a busy request to this block, we need to cancel it too
relevance 3../src/torrent.cpp:7600if peer is a really good peer, maybe we shouldn't disconnect it
relevance 3../src/web_peer_connection.cpp:586just make this peer not have the pieces associated with the file we just requested. Only when it doesn't have any of the file do the following
relevance 3../include/libtorrent/block_cache.hpp:212could this be a scoped_array instead? does cached_piece_entry really need to be copyable? cached_piece_entry does need to be copyable since it's part of a container, but it's possible it could be a raw pointer or boost::unique_ptr perhaps
relevance 3../include/libtorrent/disk_io_thread.hpp:537turn these counters and gauges into session_stats counters (which also would need to be thread safe)
relevance 3../include/libtorrent/policy.hpp:104this class should be renamed peer_list
relevance 3../include/libtorrent/session.hpp:210could the fingerprint be a setting as well? And should the settings_pack be optional?
relevance 2../src/disk_io_thread.cpp:844should this be allocated on the stack?
relevance 2../src/disk_io_thread.cpp:885we're not flushing the read cache at all?
relevance 2../src/file.cpp:1491use vm_copy here, if available, and if buffers are aligned
relevance 2../src/file.cpp:1502use vm_copy here, if available, and if buffers are aligned
relevance 2../src/session_impl.cpp:2568use bind_to_device in udp_socket
relevance 2../src/session_impl.cpp:4599make a list for torrents that want to be announced on the DHT so we don't have to loop over all torrents, just to find the ones that want to announce
relevance 2../src/torrent.cpp:699post alert
relevance 2../src/torrent.cpp:4646abort lookups this torrent has made via the session host resolver interface
relevance 2../src/udp_tracker_connection.cpp:64it would be nice to not have a dependency on session_impl here
relevance 2../src/web_peer_connection.cpp:645create 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/node.cpp:67make this configurable in dht_settings
relevance 2../src/kademlia/node_id.cpp:135this could be optimized if SSE 4.2 is available. It could also be optimized given that we have a fixed length
relevance 2../include/libtorrent/enum_net.hpp:137this could be done more efficiently by just looking up the interface with the given name, maybe even with if_nametoindex()
relevance 2../include/libtorrent/intrusive_ptr_base.hpp:44remove this class and transition over to using shared_ptr and make_shared instead
relevance 2../include/libtorrent/settings_pack.hpp:70add an API to query a settings_pack as well
relevance 2../include/libtorrent/settings_pack.hpp:71maybe convert all bool types into int-types as well
relevance 2../include/libtorrent/torrent.hpp:1184replace all usage of this with m_ses.get_resolver()
relevance 2../include/libtorrent/torrent_info.hpp:303there may be some opportunities to optimize the size if torrent_info. specifically to turn some std::string and std::vector into pointers
relevance 2../include/libtorrent/aux_/session_interface.hpp:108the IP voting mechanism should be factored out to its own class, not part of the session
relevance 1../src/http_seed_connection.cpp:111in 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:6511report the proper address of the router as the source IP of this understanding of our external address, instead of the empty address
relevance 1../src/session_impl.cpp:7664we only need to do this if our global IPv4 address has changed since the DHT (currently) only supports IPv4. Since restarting the DHT is kind of expensive, it would be nice to not do it unnecessarily
relevance 1../src/torrent.cpp:1140make 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:6780save the send_stats state instead of throwing them away it may pose an issue when downgrading though
relevance 1../src/torrent.cpp:7832should 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/kademlia/node.cpp:827find_node should write directly to the response entry
relevance 1../include/libtorrent/ip_voter.hpp:122instead, have one instance per possible subnet, global IPv4, global IPv6, loopback, 192.168.x.x, 10.x.x.x, etc.
relevance 1../include/libtorrent/web_peer_connection.hpp:121if we make this be a disk_buffer_holder instead we would save a copy sometimes use allocate_disk_receive_buffer and release_disk_receive_buffer
relevance 0../src/block_cache.cpp:884it's somewhat expensive to iterate over this linked list. Presumably because of the random access of memory. It would be nice if pieces with no evictable blocks weren't in this list
relevance 0../src/block_cache.cpp:948this should probably only be done every n:th time
relevance 0../src/block_cache.cpp:1714create a holder for refcounts that automatically decrement
relevance 0../src/bt_peer_connection.cpp:646this could be optimized using knuth morris pratt
relevance 0../src/bt_peer_connection.cpp:2213if we're finished, send upload_only message
relevance 0../src/disk_io_thread.cpp:921instead of doing a lookup each time through the loop, save cached_piece_entry pointers with piece_refcount incremented to pin them
relevance 0../src/disk_io_thread.cpp:1132instead of doing this. pass in the settings to each storage_interface call. Each disk thread could hold its most recent understanding of the settings in a shared_ptr, and update it every time it wakes up from a job. That way each access to the settings won't require a mutex to be held.
relevance 0../src/disk_io_thread.cpp:1157a potentially more efficient solution would be to have a special queue for retry jobs, that's only ever run when a job completes, in any thread. It would only work if m_outstanding_jobs > 0
relevance 0../src/disk_io_thread.cpp:1171it should clear the hash state even when there's an error, right?
relevance 0../src/disk_io_thread.cpp:1866maybe the tailqueue_iterator should contain a pointer-pointer instead and have an unlink function
relevance 0../src/disk_io_thread.cpp:2121this 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:2382we should probably just hang the job on the piece and make sure the hasher gets kicked
relevance 0../src/disk_io_thread.cpp:2452introduce a holder class that automatically increments and decrements the piece_refcount
relevance 0../src/disk_io_thread.cpp:2692it would be nice to not have to lock the mutex every turn through this loop
relevance 0../src/http_tracker_connection.cpp:96support authentication (i.e. user name and password) in the URL
relevance 0../src/metadata_transfer.cpp:359this is not safe. The torrent could be unloaded while we're still sending the metadata
relevance 0../src/packet_buffer.cpp:176use compare_less_wrap for this comparison as well
relevance 0../src/part_file.cpp:252what do we do if someone is currently reading from the disk from this piece? does it matter? Since we won't actively erase the data from disk, but it may be overwritten soon, it's probably not that big of a deal
relevance 0../src/part_file.cpp:344instead of rebuilding the whole file header and flushing it, update the slot entries as we go
relevance 0../src/peer_connection.cpp:1109this should be the global download rate
relevance 0../src/peer_connection.cpp:3278sort the allowed fast set in priority order
relevance 0../src/piece_picker.cpp:2407when expanding pieces for cache stripe reasons, the !downloading condition doesn't make much sense
relevance 0../src/session_impl.cpp:678there'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:2384instead of having a special case for this, just make the default listen interfaces be "0.0.0.0:6881,[::1]:6881" and use the generic path. That would even allow for not listening at all.
relevance 0../src/session_impl.cpp:3228should this function take a shared_ptr instead?
relevance 0../src/session_impl.cpp:3603have a separate list for these connections, instead of having to loop through all of them
relevance 0../src/session_impl.cpp:3644this should apply to all bandwidth channels
relevance 0../src/session_impl.cpp:4707these vectors could be copied from m_torrent_lists, if we would maintain them. That way the first pass over all torrents could be avoided. It would be especially efficient if most torrents are not auto-managed whenever we receive a scrape response (or anything that may change the rank of a torrent) that one torrent could re-sort itself in a list that's kept sorted at all times. That way, this pass over all torrents could be avoided alltogether.
relevance 0../src/session_impl.cpp:4782allow extensions to sort torrents for queuing
relevance 0../src/session_impl.cpp:4960use a lower limit than m_settings.connections_limit to allocate the to 10% or so of connection slots for incoming connections
relevance 0../src/session_impl.cpp:5122post a message to have this happen immediately instead of waiting for the next tick
relevance 0../src/session_impl.cpp:5156make configurable
relevance 0../src/session_impl.cpp:5170make configurable
relevance 0../src/session_impl.cpp:5249this should be called for all peers!
relevance 0../src/session_impl.cpp:5666it might be a nice feature here to limit the number of torrents to send in a single update. By just posting the first n torrents, they would nicely be round-robined because the torrent lists are always pushed back
relevance 0../src/storage.cpp:710make this more generic to not just work if files have been renamed, but also if they have been merged into a single file for instance maybe use the same format as .torrent files and reuse some code from torrent_info
relevance 0../src/storage.cpp:1006if everything moves OK, except for the partfile we currently won't update the save path, which breaks things. it would probably make more sense to give up on the partfile
relevance 0../src/torrent.cpp:489if the existing torrent doesn't have metadata, insert the metadata we just downloaded into it.
relevance 0../src/torrent.cpp:639if the existing torrent doesn't have metadata, insert the metadata we just downloaded into it.
relevance 0../src/torrent.cpp:1444is 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:1836instead of creating the picker up front here, maybe this whole section should move to need_picker()
relevance 0../src/torrent.cpp:2032there 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:2705this 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:3236instead, borrow host resolvers from a pool in session_impl. That would make the torrent object smaller
relevance 0../src/torrent.cpp:4427update suggest_piece?
relevance 0../src/torrent.cpp:4570really, we should just keep the picker around in this case to maintain the availability counters
relevance 0../src/torrent.cpp:6480make 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:6643if 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:6837make 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:8751add 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:9694go through the pieces we have and count the total number of downloaders we have. Only count peers that are interested in us since some peers might not send have messages for pieces we have it num_interested == 0, we need to pick a new piece
relevance 0../src/torrent.cpp:10340instead of resorting the whole list, insert the peers directly into the right place
relevance 0../src/torrent_peer.cpp:179how do we deal with our external address changing?
relevance 0../src/udp_socket.cpp:290it would be nice to detect this on posix systems also
relevance 0../src/udp_tracker_connection.cpp:554it would be more efficient to not use a string here. however, the problem is that some trackers will respond with actual strings. For example i2p trackers
relevance 0../src/upnp.cpp:72listen_interface is not used. It's meant to bind the broadcast socket
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:1621this loop may not be very efficient
relevance 0../src/web_connection_base.cpp:71introduce a web-seed default class which has a low download priority
relevance 0../src/kademlia/dht_tracker.cpp:428ideally this function would be called when the put completes
relevance 0../src/kademlia/routing_table.cpp:308instad of refreshing a bucket by using find_nodes, ping each node periodically
relevance 0../include/libtorrent/bitfield.hpp:158rename to data() ?
relevance 0../include/libtorrent/block_cache.hpp:220make this 32 bits and to count seconds since the block cache was created
relevance 0../include/libtorrent/config.hpp:339Make this count Unicode characters instead of bytes on windows
relevance 0../include/libtorrent/debug.hpp:212rewrite this class to use FILE* instead and have a printf-like interface
relevance 0../include/libtorrent/disk_buffer_pool.hpp:133try to remove the observers, only using the async_allocate handlers
relevance 0../include/libtorrent/peer_connection.hpp:217make 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:1145factor this out into its own class with a virtual interface torrent and session should implement this interface
relevance 0../include/libtorrent/peer_connection_interface.hpp:45make this interface smaller!
relevance 0../include/libtorrent/performance_counters.hpp:132should keepalives be in here too? how about dont-have, share-mode, upload-only
relevance 0../include/libtorrent/performance_counters.hpp:404some space could be saved here by making gauges 32 bits
relevance 0../include/libtorrent/piece_picker.hpp:669should this be allocated lazily?
relevance 0../include/libtorrent/proxy_base.hpp:166it would be nice to remember the bind port and bind once we know where the proxy is m_sock.bind(endpoint, ec);
relevance 0../include/libtorrent/session.hpp:856add get_peer_class_type_filter() as well
relevance 0../include/libtorrent/settings_pack.hpp:1074deprecate this ``max_rejects`` is the number of piece requests we will reject in a row while a peer is choked before the peer is considered abusive and is disconnected.
relevance 0../include/libtorrent/size_type.hpp:48remove these and just use boost's types directly
relevance 0../include/libtorrent/torrent.hpp:1190this wastes 5 bits per file
relevance 0../include/libtorrent/torrent.hpp:1249These two bitfields should probably be coalesced into one
relevance 0../include/libtorrent/torrent.hpp:1591there's space for 1 bits here
relevance 0../include/libtorrent/torrent_info.hpp:124include the number of peers received from this tracker, at last announce
relevance 0../include/libtorrent/upnp.hpp:113support using the windows API for UPnP operations as well
relevance 0../include/libtorrent/utp_stream.hpp:391implement 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:412move the login info into the tracker_request object
relevance 0../include/libtorrent/aux_/session_impl.hpp:900should this be renamed m_outgoing_interfaces?
relevance 0../include/libtorrent/aux_/session_interface.hpp:200it would be nice to not have this be part of session_interface