Installation notes are contained elsewhere, but adding the use of screen would be advisable and the use of CTCS optional. Installed :
unslung 6.8, ctorrent 1.3.4-2, enhanced-ctorrent dnh3.2-9, ctcs 1.4-8
tested on public and private trackers with high and low peer count torrents
Intitiate single new torrent with the command:
enhanced-ctorrent -C 4 -m 40 -S localhost:2780 filename.torrent
where option "-C 4" provides 4mb cache, "-m 40" sets minimum peers to 40 and "-S" sets the web interface to local port 2780 (dependant on having installed CTCS). Having played around with cache settings it seems that the slug works fastest with some ram cache allowed. The minimum peers setting is supposed to trigger an "update tracker, get more peers" function but this doesn't seem to work as designed, so this works as a default to a median number of peers for a speedy download/upload.
Upload and download rates are controlled from the CTCS web gui where they can be changed to suit, usually 10-20 kb/s less than your ISP allowance.
Some trackers do not like this client and some clients seem to have aggressive settings where the slug/dnh just doesn't get a look in. This has been compared with testing the same torrent with 3 different clients - Azureus 3.x/winxp, Rtorrent0.7/Debian and dnh3.2/unslung.
Previously, after checking the tracker connection from the command line I have then made the client switch to daemon mode but now I just use screen as there are occasions when the client hangs at cpu +95%. This seems to be related to the floating point exception noted elsewhere in the nslu2 mailing lists.
In my instance, because of my ISP, I need to be able to stop downloading during peak times and switch to just seeding a different torrent already completed. To stop the client properly you must use either the Quit command from the CTCS web gui or the command line and allow the client and tracker to complete their update properly or you will get errors in the pieces check. This is noted mainly in large torrents of 3gb (some reports at 2.5gb) and over where the client fails to properly account for pieces already downloaded, so when a new session is started and the client performs a piece check the amount verified is less than actual, to the tune of 10 to 30% less.
To seed a completed torrent use the following:
enhanced-ctorrent -C 4 -f -S localhost:2780 filename.torrent
where option "-f" forces the client into seed mode without checking for piece completion.
Fails to properly read/write bitfield file and/or check for pieces of torrents over approx 3gb (some reports at 2.5gb).
Not favoured by many other torrent clients/trackers, so downloads will be slow whereas uploads will be nominal.
Has no global stats or multi-session stats, so user onus applies.
Not particularly aggressive at getting more peers so downloads can slow until user forces "update tracker".
While this isn't the place to discuss torrent etiquette, using this client on the unslung requires the user to be more conscious of their share ratio...
According to the ctorrent project page as of the 27th November, a bug has been spotted in the btfiles.cpp file where you can delete the "setvbuf" line and recompile. This fixes a completed torrent reporting as incomplete upon restart error. This is probably related to the bitfield error mentioned above. An updated version with this fix, enhanced-ctorrent_dnh3.2-10, is available at the Optware feeds. Simply run
Hint for enhanced-ctorrent users: changing the user agent and peer id may help with torrent speeds...
example for seeding a newly created and uploaded torrent:
enhanced-ctorrent -c -f -A "uTorrent/1610" -P "-UT1610-" -C 4 -m 40 -S localhost:2780 -s /torr1/ torr1.torrent
example for downloading:
enhanced-ctorrent -P "-UT1610-" -A "uTorrent/1610" -C 4 -m 40 -S localhost:2780 -s /share/hdd/data/HDD_1_4_1/torrent2/ torrent2.torrent
The -P "-UT1610-" sets the peer id to that of uTorrent 1.6.1 The -A "uTorrent/1610" sets user agent as uTorrent 1.6.1
Frequenlty doing an Update .o. Update tracker stats & get peers seems to keep torrents seeding/downloading going well.
ALL of this can really work quite well and this seems to help most of the time.
The changing of the client ID that gets reported to the tracker is not the best of ideas and should be avoided. The client develops a reputation with tracker admins over time based on the ability of the client to faithfully report statistics and not poll the tracker too often. Other behaviours are noted to be unfriendly and exploitable, as shown here http://www.ics.uci.edu/~msirivia/large-view/index.html
It is up to the developer(s) to make the client function following the protocols correctly otherwise it gets banned. Personally, I changed clients to rtorrent on unslung and have no problems apart from lack of global statistics.
Dynamic bandwidth eventually slows download(s)& uploads --> Work-Around:
UnSLung 6.10 Enhanced-CTorrent dnh3.3.2 ctcs 1.4.1
With one or more torrents downloading from high speed seeders running CTCS set all torrents Shared-DL and Minimum-DL Maximum-DL set to 0 [ 0 to disable/remove a limit ] and global bandwidth set plenty high enough to accommodate.
What happens is that after an indeterminate period of time ( typically 30 minutes to several hours) one ( or more ) torrent(s) will slow to 8kB/s or less. IF now disable Shared-DL on all and set Current.Limit-DL to 0s the download speeds are OK.
If set to Shared-DL on any of the slowed/stalled torrent the 8kB/s limit returns. Backed to disabled Shared-DL download speed OK again.
This has been confirmed over a period of several months on 2 separate NSLU2s at different locations/IP providers and different trackers.
With Shared-DL on and setting the Minimum-DL to anything greater than 8kB/s always results in an 8kB/s or less speed with any of the slowed torrents.
With Shared-DL off and setting the Current.Limit-DL to anything greater than 8kB/s always results in an 8kB/s speed or less with any of the slowed torrents.
The UpLoad dynamic management encounters nearly identical problems. ** FIX is the same as for DL; Disable Shared-UL on all and set Current.Limit-UL to 0s the upload speeds are OK.
With Shared-UL on and setting the Minimum-UL to anything greater than 4kB/s always results in an 4kB/s or less speed with any of the slowed torrents.
With Shared-UL off and setting the Current.Limit-UL to anything greater than 4kB/s always results in an 4kB/s speed or less with any of the slowed torrents.
Also note that with both Shared-DL AND Shared-UL ALL set to off that the download speed may then become limited to that of the uploads total speeds. This may be because most BitTorrent peers use a variant of Tit for two Tats which is called optimistic unchoking in BitTorrent terminology. BitTorrent peers have a limited number of upload slots to allocate to other peers. Cooperation is achieved when upload bandwidth is exchanged for download bandwidth. Consequently, when a peer's upload bandwidth is saturated, it will use a Tit for Tat strategy. Optimistic unchoking corresponds very strongly to always cooperating...
Because of this you may not want to Disable Shared-UL on all until downloads are complete.