Alo Sarv
lead developer

Donate via

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

Tuesday, August 30, 2005

Progressing ....

First of all, thanks for the comments on last post, it gave me several ideas, which I hope the implement in near future. Simple, yet powerful GUI - got it covered. The more I think about it, the more I tend to fall towards the idea of releasing standalone BT client as soon as the BT code is working. Whether or not it'll also have ed2k support is an open topic, but I have some ideas on that area as well.

Anyway, I'v been testing BT myself some now (using Azureus) - hadn't really used BT for a while myself - and am now starting to get the right "feeling" about the protocol / network / however you call it. There are things still that aren't mentioned in any protocol docs that I'v seen, for example upload management - how many slots to keep open? Based on what I see in Azureus, it seems to keep 3x6kb/s slots open with 20kb/s limit... the connection-management is still a mystery to me, w/o queue handling... anyway, from what I can see, uploading is done to the same clients from where we download (fair enough), but many connections seem to stay "0 down, 0 up" state, others "xxx down, 0 up" state ... ohwell.

Anyway, our implementation got some updates today, altough nothing fancy yet - we have initial client-name detection (useless, but better than deciphering the cryptic peer-id), and we'r moving towards chunk-requests, but ran into some trouble in there - PartData doesn't seem to want to give me any ranges to download, keeps bailing out on PartData::doGetRange() method... the wierdest thing is that it works for ed2k (I nearly copy/pasted some of the code from ed2k module), but not for BT... perhaps our customized PartData class in BT module is to blame?

Madcat, ZzZz

Btw, it would make sense to use an incomplete file system compatible with other BT clients, eg the official client, and Az can resume each others downloads, however this may not fit in well with the design of hydranode.
We can have import/export function for temp files (as we already have for emule files), but we can't use the same format as they do - it doesn't fit Hydranode design.

Post a Comment

<< Home

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