📄 changelog
字号:
for SHA1 support. See the INSTALLING file for information about how to override this or give a hint to configure about where to find the files. * Added autoconf checks for integer types that may not be defined on some systems. * The funny business with cfg_max_slice_size is eliminated since request slice size is based on user option rather than a fixed request queue size. * Moved bandwidth limiting functions from peer.* to peerlist.* * Relocated and rewrote get_nl and set_nl. * Replaced hard-coded message component length values with constants. * Formatting adjustments. _________________________________________________________________ Changes for "dnh2.2" Release Code Fixes * Fixed checking of seed ratio (-E option) to allow fractional values. * Fixed CTCS interaction when a limit was not specified on the command line. * Fixed peer reconnect determination. * Fixed a request-queue handling error that could cause a crash upon becoming a seeder. * Fixed creation of metainfo (torrent) file with multiple subdirectories. * Torrent metainfo is now only printed twice if hash-checking is performed. Operational Enhancements * Errors flushing the cache are now handled more gracefully. (This happens when the disk is full.) * Added additional seeder detection criteria. * Cleaned up parts of the help screen. _________________________________________________________________ Changes for "dnh2.1" Release Code Fixes * Fixed interaction with CTCS under Linux, resulting in "Operation now in progress" errors. * Fixed a flaw in optimistic unchoke logic implementation. * Fixed problem with return value in _btf_ftruncate() related to my update for the vfat issue [btfiles patch]. * Fixed handling of 301/302 redirect response from the tracker. Operational Enhancements * Attempt to reconnect to successful peers that disconnect unexpectedly, if possible. * Changed the unchoke choice algorithm when seeding. The new method is based on page 4 of the paper "Rarest First and Choke Algorithms Are Enough" by Arnaud Legout et al. An exception is that CTorrent chooses new unchokes using its original method (based on wait time) rather than randomly. See [1]the paper for details. _________________________________________________________________ Changes for "dnh2" Release Patches * The following patches or their functionality are incorporated: 1380164 [dnh1.2] 1357832 [invert] (included in dnh1.2) 1352866 [dnh1.1] 1266767 [passkey2] 1239547 [dnh1] 1170457 [standalone-sha1] Added as a fallback case in configure if OpenSSL is not found. To force it to be used, define USE_STANDALONE_SHA1 in config.h (after running configure). 1164454 [ip] 1119610 [vfat] This bug appears to be linux-specific; I've tried to handle it in a more general way that may apply to similar situations on other platforms and filesystems, but I have limited capability to test this. 1067196 [lfs] This is the large-file support that many have asked for. Optimization * Use fewer calls to random() by shifting the previously unused bits. * Time() calls have been greatly reduced; a global timestamp variable "now" is set once per main loop iteration and referenced in functions that need a timestamp (except the caching I/O routines which were left alone). * Overall current bandwidth rates are now computed only once per main loop and referenced in any routines that evaluate or control bandwidth. * Avoid flushing peer output buffers except in SendModule. This allows for some consolidation of messages to reduce network overhead. Code Fixes * Fixed use of cfg_req_queue_length to be the actual queue size (queue was half of this value). * Fixed: "peer is" verbose output could fubar the terminal. * Formatting: Replaced indentation tabs with spaces for consistency. Operational Enhancements * Improved piece selection methods to include rarity as a factor. This is not strictly "rarest-first", as we do not make a comprehensive effort to find the "rarest" piece or rank pieces by rarity. Rather, we use a more efficient compromise and try to find the set of pieces that have "trade value" (another peer needs them) and make a random choice from that set. Here is the current preference order used in each mode: Trade Value is defined as: 1. Piece that only this peer has (not considering other seeders), that a peer in which we're interested needs. 2. Piece that not every peer in which we're interested has. 3. Piece that only this peer has (not considering other seeders). 4. Piece that not every peer has. Normal Mode 1. Piece we tried to get from another peer but stopped due to choking or lost connection. (We have part of the piece already.) 2. Piece most recently acquired by the peer (possibly/probably rare). 3. Piece with trade value. 4. Any piece not yet requested. Initial-piece Mode 1. Piece with trade value which is already in progress. 2. Piece with trade value that more than one peer has. 3. Piece with trade value. 4. Any piece not yet requested. Endgame Mode 1. Piece with trade value which is already in progress, of which we have the least amount. 2. Piece already in progress of which we have the least amount. * Advanced request queueing system. + Instead of requesting all of the slices for a piece at one time, we now measure latency to the peer and send requests based on how long it takes the data to arrive. This avoids wasting upload banwidth by having too many outstanding requests: If we get choked or lose the connection, the extra requests were wasted; in initial or endgame modes, more requests would have to be cancelled when we completed the piece. + A new piece will be queued for download when there is space in the queue and we've requested the slices that have been queued already. We also don't wait for the current piece to complete before sending requests for a new piece. This helps to maintain a continuous flow of data in the download pipeline. + When duplicating a request in initial or endgame mode, slices that have already been requested are queued last. * Don't send HAVE messages to seeders (to save UL bandwidth). + Since we maintain interested state, and know the peer is a seeder, we'll do the right thing when we become a seeder. + Not sending HAVE to all peers (leechers) that already have the piece is a bad idea IMO. If everyone takes the same attitude, none of us will know when another becomes a seeder and connections will remain open/occupied. + We do send a HAVE to seeders upon completing our first piece so that we don't continue to appear empty. * Endgame strategy is used in get1file mode to complete the file. * Queue management: + Don't accept requests from choked peers. + Discard peer's reponse_q when we choke them. + Don't send cancels when we get choked (according to spec & discussions). + Don't put full piece queues in pending. + Move closing peer's request queue to pending instead of discarding it. * Prefer uploading to or downloading from a peer after we skip them due to bandwidth limiting. This is done via the g_next_up and g_defer_up global variables in peer.cpp (for UL; s/up/dn for the DL versions). The peerlist Sort() function and peer "click" variables have been removed since they are not needed with this feature. Options & Features * The -c option now reports file completion status. + As a side effect the metainfo details are printed twice. This allows you to view the torrent contents while pieces are being verified. + Total percentage completion is also added to the output. * "-E" option to seed to a specified UL:DL ratio. Seeding will stop when this ratio or the timeout (-e) is reached. If CTorrent starts as a seeder, the ratio is interpreted as UL:[torrent size]. * If "-e 0" is specified (explicitly) and -E is used, there will be no timeout; seeding will continue until the ratio is reached. * The "-m" option previously didn't do anything, and it isn't clear what it was originally going to do. Now the default value is 1, and CTorrent will try to maintain at least this many peers by contacting the tracker early if the peer count falls below this value. This feature was present in release dnh1 but the value was not changeable. Actually it seems likely that this was to be number of peers that the client would try to obtain (by initiating connections), as the "official" client does; this is mentioned as a note in the online specification. I don't really see the value in that though. That said, the option as implemented here should rarely be used. It might be useful only with torrents that have significantly more than max_peers total peers and use a long tracker update interval (such that you tend to drop a lot of peers betwen updates). * "-z" option to set the slice size (the unit of a request, i.e. the discrete amount of data that will be requested from a peer at one time). The slice size now defaults to 16K regardless of the piece length. Request queue size is computed and set based on the slice size, as it now affects only system resources (though not a lot) and not the way that requests are sent. * Add support for "key" and "trackerid" tracker interaction parameters. * Support/display tracker warning message * Now able to handle torrents with more than 255 files. * Support for [2]CTorrent Control Server, an application and protocol for monitoring and managing multiple Enhanced CTorrent clients. The "-S" option is used to connect to CTCS, as in "-S localhost:2780" if CTCS is listening at port 2780 on the local system. Appending a colon ("-S localhost:2780:") will prompt for a password to authenticate with CTCS. Peer Handling * Count immediate choke-unchoke (either order) as an error (two errors actually, since it's so wasteful). It may be that some clients do this to stimulate the peer when
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -