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