Alo Sarv
lead developer

Donate via
MoneyBookers

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary
irc.hydranode.com/#hydranode

Sunday, January 29, 2006

More shell features and such

Something that's been bugging me (and possibly other users as well) has been the lack of displaying known file names for downloads, since this is one of the main ways to determine whether the file is fake or not. Now, using the new 'vd #num' command, hnshell displays 15 most popular file names of the download along with frequency, as well as all comments that have been found so far. Note that neither of these fields are stored across sessions (to keep them up to date).

Additionally, hnshell now displays ETA value (when file availability is 100%), which shows how many days, months or hours are left to download completition. Here I ran into a small problem with the 78-character line-length limit of hnsh (from win32 console), so I decided to trim the ETA value to two up-most entries. E.g. if it is estimated to take more than, say, 2 months to complete a download, it only displays months and days, while if it is estimated to take under a hour to complete the download, it will display minutes and seconds. This way most relevant information is displayed without cluttering the output.

In bittorrent module, if you can remember we are using cache folder (config/bt) for cross-file data as well as .torrent files. In some cases, this amount of data can span hundreds of megabytes (when torrent consists of many small files), but usually it's only few megabytes. Nonetheless, until now the cache folder was never cleaned up. Now we perform cache folder cleanup - deleting all torrents and cache files for torrents that are no longer being seeded or downloaded - on startup.

There was a bug in BT uploading handling where when attempting to switch upload slots to other clients, we actually switched it back to the client that we took the upload slot from in the first place, which resulted in instant choke + unchoke combination, hurting overall upload speed stability of the module. This no longer happens - when switching upload slots, we determine which client will get the slot, and if the client matches the one that we'r about to take the slot away from, we simply give the client another 30 seconds upload time before checking again.

Related to the last change, in order to avoid many clients being choked + unchoked at same instant, we now use variable-length upload sessions - current implementation uses 30 += 3 seconds timeframe.

Madcat, ZzZz



Comments: Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?