A few days ago, gcostanza made an assertion in the forums, indicating:

"BT is a complex network too - like ed2k and G1/G2. I just have to know how the object model of Hydranode would hold against that. I somehow have the feeling there are a lot of donkey-isms in it at the current stage."

Well, I'm up for the challenge. It is true that I'v been promising a multi-network client since the beginning, but not backed up that promise with deeds thus far, so the assertion is fully valid and justified.

It is also true that Bittorrent is a complex protocol, but the complexity at the application level is not the protocol itself - but rather from the way it handles files - or more importantly - the lack of it. As I discovered a while ago, Bittorrent doesn't have files, not at protocol level. Instead, it handles all torrent data in a continuous stream (obviously used as optimization-technique - imagine 5000 files, each 50-bytes in size - how large would a .torrent file be? How many hashes would it require if there was one hash per file? etc).

The issue behind designing Bittorrent plugin is not that there would be lot of donkey-isms in the core right now, but rather the opposite - how to implement Bittorrent in such a way that it would least interfere with the other networks (that use "normal" files handling).

Today, I believe I have resolved the problems related to files handling in Bittorrent module, and thus wrote up an initial design document on it. So, without further talk, here it is:

Hydranode Bittorrent Module Design

Madcat, ZzZz