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

Wednesday, August 17, 2005

Moving on

As usual, there was few days wind-down time after the release, but now we'r getting back on track. Yesterday, I was working on adding UPnP support into Hydranode, and it went well - we have a basic router-detection, ports adding and removal support. A manual test application is included (called "pfwd"), that is capable of adding/removing ports. Further integration into Hydranode systems will be something for later.

Today I was working on upgrading the internal boost sources and tools to Boost 1.33. That went seamlessly, everything seems to be working as before. The highlights in Boost 1.33 that affect Hydranode most are Boost.Signals major performance upgrade (Hydranode event engine relies on signals), hashed indices to multi_index and compressed iostreams support in Boost.IOStreams library. It is yet to be determined how much does the Signals upgrade affect Hydranode's performance, but based on what I'v seen in Boost mailing lists, the performance boost was said to be major. Hashed indices will require manual code updating to take advantage, but will speed up a lot of lookups in containers. As for compressed streams, these will be put to use in ed2k module, where we (still) lack proper support for compressed downloads, due to lack of stream-based decompression - I was waiting for Boost 1.33, instead of rolling my own there.

Anyway, after some discussions, we came to the conclusion that the most important thing to continue working on right now is Bittorrent. The reason is simple - Hydranode is supposed to be multi-network client. Hydranode is built from ground up with multi-network in mind. All major components in Hydranode are multi-net-aware, and took several times longer to develop just because of that; and now we'v been sitting on this piece of code for countless months already, only using it for single-net, and this is unacceptable. The GUI is irrelevant at this stage, because as long as we don't have multiple networks, we'r simply throwing away countless months of work that went into generic engine components such as Range API, PartData, Hasher API etc. There are people still working on GUI designs, but I'll be at hncore/bt/ dir for a while now.

The first target is to successfully parse (and store information) from .torrent file. Considerining that the .torrent file contains the most complex BT protocol structure (a map with nested strings, integers, lists and submaps), if I can successfully parse that, the rest of the protocol is a piece of cake.

Now, as mentioned before, I want to parse BT protocol using Boost.Spirit, because it's really fast and very powerful parser engine. However, with power, comes complexity. I'v done some studying of the library in the past, and I spent a measly 4 hours on it today as well, with little progress - those guys who wrote that thing are insane :). Right now, it feels like banging head against the wall. Hopefully, the morning brings clarity and progress towards that end.

Madcat, ZzZz

PS: Apparently, I forgot to enable support for files >2GB in the 0.1.2 release (it's fixed in SVN), so I might need to do a 0.1.3[hotfix] release sometime soon....

Really nice to hear that you have worked on UPnP support. :)
Also I'm looking forward to see how it work with multiple networks. I hope everything is working well.
Wonderful news for the Roadmap. I can't wait for Madcat (tm) BT implementation but more than anything else I can't wait for Madcat (tm) documentation of the BT protocol. I like code but IMHO your docs are an immense contribution to FOSS and I've seen them quoted on several dev sites and forums (including official emule). :) BTW libtorrent uses boost in case you get stuck but I'm sure you can manage from scratch too. Greetings.
Post a Comment

<< Home

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