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

Tuesday, November 01, 2005

More ed2k performance analysis and improvements

Since we kinda got into the "groove" already with the ed2k performance tuning topic, and since we have the tools for doing it in a fast manner, while having proper statistical results after each change, we continued the topic today with chemical, with very positive results. Overall, we noted radical overall performance improvent in downloading, queue and upload management. While your milage may vary, the list of fixes should say enough:
A very special thanks to chemical for assistance in testing and analysing the hundreds of megabytes of logfiles Hydranode produces, and the perl scripts used for analyzing that data.

On other news, I'm running another ed2k+bt cooperative downloading test, the test torrent includes about 9 files, and hashes for ed2k network; there are about 30-40 peers on BT for this torrent, and total of 150 clients on ed2k for these files. It's really interesting to watch how well ed2k and BT protocols complement each other in case of rare files - sometimes BT download stalls for hours, but the ed2k kicks in, and sometimes vice versa - resulting in overall steady download-rate of 20-80kb/s, which for this rare stuff is pretty good.

Bottom line: There are new optimized builds available, for Windows and Linux, including BT module, which is now open for public testing. While there are some known issues with it, I think it's good enough to warrant more wider testing. Additionally, Linux debug build is available (19mb download, over 100mb when unpacked), and for completeness, source code tarball. Enjoy :)

Madcat, ZzZz



Comments:
CreditDb file 'clients.met' write bug still exist in the latest snapshot. Hope it's been fixed in the next step. :)

Madcat, thanks a lot for making us the good client, which has brilliant future.
 
Thanks you very much for the testbuild, it works out of the box on my suse 8.2 server.
mem: virt:8380 res:8376 sha:6304
Now let's see about the memory-leakage and runtime stability.
 
I can't figure out how to use my guarding.p2p file. Any hint would be appreciated.
 
Madcat, you are an awesome developer, your code must to readed for everyone developer who wants to coding in a proffesional manner and you are documenting Hydranode very good. I think Hydranode soon will be the best P2P (and other "file-sharing" networks) client in the world and winning some nice awards because the quality of the project. Thanks to a few people like you, we are starting to have really high code quality open-source projects ;)

I hope soon after the important stuff if needed (bugfixing, improving BT protocols and others), some small features like automatic guardian_full.p2p/ipfilter updating and other stuff for avoiding leeching or P2P contamination can be added soon.

Thanks a lot for Hydranode, you are my hero. I want to be a programmer as you in the very long future...
 
WOW! collaborative download as been my dream in a long long time!

Thanks for the work u do! well done!
 
Is there any way how to configure the port which the bt plugin is using?
 
me to, I meen I need to change the BT port to. Many closed-group tracker dont't support the default 6882 port.
It looks like hardcoded in the source :-(
 
Will be possible to change the port from conf soon, and thanks for the info on the default port - we'll use 6883 as default port then (just as we'r using +1 values in ed2k default ports).

Madcat.
 
> we'll use 6883 as default port then

Sorry, but that is not sufficient.

From the FAQ of a closed-user tracker:

Why do I get a "rejected by tracker - Port xxxx is blacklisted" error?

Your client is reporting to the tracker that it uses one of the default bittorrent ports (6881-6889) or any other common p2p port for incoming connections.

We do not allow clients to use ports commonly associated with p2p protocols. The reason for this is that it is a common practice for ISPs to throttle those ports (that is, limit the bandwidth, hence the speed).

The blocked ports list include, but is not neccessarily limited to, the following:

Direct Connect 411 - 413
Kazaa 1214
eDonkey 4662
Gnutella 6346 - 6347
BitTorrent 6881 - 6889
 
Post a Comment



<< Home

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