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

Friday, August 26, 2005

Tracker communication implemented

Well, we have basic client <-> tracker communication up and running. Basically, it all comes down to one HTTP GET request, and the response to that. This request / response is done every now and then, and that's about all the client <-> tracker communication there is, as far as I know.

The files, for your viewing pleasure (sorry, undocumented):

Now, from that we got the peer listing; next logical step is set up the neccesery data structures for handling the peers. I'm thinking along the lines of multi_map<Client*, Torrent*, PtrLess<Client> >-like container. In english - a non-unique map of clients (sorted by ClientId), allowing cross-referncing Client and Torrent. Why non-unique? Because same Client can be related to multiple torrents (contrary to my erronous statement last night).

Now, when clients contact us, we can wait for the handshake, and then look up the client based on the received PeerId, and "merge" with the existing object, pretty much similarly as we do in ed2k. That merging busyness is damn tricky (took quite some time to get it right in ed2k module), but it's unavoidable as far as I know. I just hope we'v learned from the mistakes made at ed2k module.

Speaking of listeners - an interesting topic raised today on our IRC channel - namely, it was pointed out to me that ShareAza somehow manages to work multiple protocols with only TWO ports - one TCP and and UDP. Now, I haven't confirmed this behaviour personally yet, but, it's interesting find indeed. The interesting part is that then you only need to open two ports total in firewall, instead of a ton, as it tends to be the case in multi-net clients.

After some thought, I figured out a way how to accomplish this (I don't know how they do it, but I presume in a similar way). While I don't have free time right now to implement it, this could indeed be a valuable feature, if done right. However, I'm a bit skeptic about the possible performance issues with this approach, since it would require client-level checks / parsing for all incoming connections, something that would otherwise be done at OS level, in much more compact way.

Anyway, I intend to implement this support when I have some free time (possibly after BT), and implement it as optional feature, so as to not break any existing stuff, and to test possible performance issues.

Oh, btw, regarding Madcat(tm) Bittorrent Protocol Spec, I'm not so sure it's neccesery - there's enough _good_ BT protocol documentation out there already, I don't think it's neccesery to create yet another one, with nothing interesting to add. For eDonkey2000 network, it was worth it, since there isn't that much docs on it on the net, but BT protocol specs are available everywhere.

Madcat, ZzZz

Post a Comment

<< Home

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