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

Thursday, August 25, 2005

Thoughts, design and what about trackerless?

Mkay, now that we have the wrappers around SharedFile / PartData, the next thing we need is some kind of object to govern those two, and contain all the networking stuff for this torrent. As much as I know about bittorrent protocol, same client cannot offer multiple files (at least I'm not aware of any bt client supporting it - any1?). Hence, this would simplify the module design somewhat.

Namely, we'll create a Torrent class (could probably use a better name), which owns the TorrentFile/PartialTorrent objects, as well as handles all the networking. Each peer would go to Client class (yes, I know the BT terminology calls them "peers", but I prefer keeping the concepts consistent across modules). Clients would be created and owned by the Torrent class. This means we won't have to implement a separate ClientList class, as in ed2k module.

Now, based on that, and from my (still very limited) knowledge of the BT protocol, Torrent will communicate with the tracker, receive clients, construct and maintain the clients, and perform the seeding/downloading. This does put the majority of the module implementation into a single class, but then again, same happened in ed2k module, where all of the protocol logic was handled by single class - Client; actually I did move a ton of stuff into helper, created-on-demand classes in ed2k module, so if the Torrent class gets too big, we can consider that option as well.

What has me worried a bit here is how trackerless torrents fit into the scheme. You could say "dont worry about trackerless right now" - but you can't, we have to consider this right now, since we just don't have the resources to rewrite large parts of the code when, say, we discover that the trackerless stuff doesn't fit into our design at all.

Another interesting thing I discovered today while going over the official protocol specs was this:
"d4:spaml1:a1:bee corresponds to {'spam': ['a', 'b']}"
Hum? How am I supposed to parse that in a generic way? There's no way for a parser to know wether what it's reading is next map key, or a subvalue. What if you encounter input such as:
"d4:spam1:a1:bee:4:span1:c1:de". While in the first case, the parser could "assume" that the last value is also a value to the preceeding key (since the total number of arguments to "dict" was odd number (3), however in the next (home-made) sample, the parser can't make that assumption, and would incorrectly parse {'spam':['a'], 'b':['span'], 'c':['d']}.

In reality, I doubt such situation happens in the protocol, and even if it does, my current protocol handling can easily be customized to handle the situation, however things such as these destroy the possibility of creating generic parser engine which doesn't care about the content being parsed, and you know I'm a fan of those :).

Madcat, ZzZz



Comments: Post a Comment



<< Home

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