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

Monday, October 24, 2005

Careful coding

Sometimes people (including myself) wonder why does Hydranode development take so long. I'v been at it, for like 1.5 years already, the most recent module (bt) has taken 2.5 months already - where is all this time going?

The problem with limited developer resources is that you can't slap things together, hope they work, move on, and later go back and fix things that break. It just doesn't work that way - you just end up with a ton of half-finished components, and yourself juggling between them - it can take years to properly stabilize the code then. Alternative solution is write everything right the first time; easier said than done though. The key is to approach every component of the app so that at some point, you can say to yourself "ok, this is finished", and forget about it. This way you can move on in a steady, albeit slow, space, and can always rely on earlier components to do their job.

This is also one of the reasons why I declared the Console application (first attempt on GUI-related things) obsolete - it just doesn't work. The reason was I took way too many things at once - Core/GUI comm protocol, the support library, GUI's internal data structures, and the visual representation of the data itself. You can't juggle between four distinct components - you have to build step-by-step.

Another thing you learn when developing alone for long periods of time is that you cannot afford bugs / mistakes - the cost of going back to fix something is far greater than that of writing it right the first time. This is different from corporate development, which have large resources - they have one set of developers working on new stuff, and other set of developers cleaning up the old mess; when working (nearly) alone, you don't have that luxury.

The most current problem at hand is BT module's files handling. As you know from previous posts, there are a lot of different usage scenarios there - files could be canceled from within the torrent at any point; they could be paused... or they might already be completed, or not existing anymore either. We'v approached this problem from multiple ends, the most recent being the implementation of Cache manager, which caches all cross-file chunks. Today I also added PartData::dontDownload() method, which allows customizing the chunk-selector to skip past specific ranges. It's not that simple though - if we simply mark all missing files in a torrent as dontDownload, we still need to download overlapping chunks, e.g. to cache. So basically, after marking all missing files as dontDownload, we must also unmark the ranges that cross file boundaries, since we still need those; the already complex writing and verifying code will become even more complex, since it must handle the case where files are missing, anywhere in the chunk.

In related news, some smaller issues in BT::Client were fixed (used range was never reset), uploading code works as per BT spec again, and uploadrequests can now be properly canceled. I also added ComponentStatus page to our wiki, which gives a proper overview of various Hydranode components and their status.

Madcat, ZzZz



Comments:
Take you time! Always do it right!
I very much apreciate your coding and am very excited about the final product. I can't wait until you finished the BT thing that I finally can start to test HN in a productive environment.
I'm reading your blod daily and learned much about how complex BT is. I always thought it was the simplest p2p app out there. (And that might be correct, but for the functionality it has it looks quite complex...)
 
I prefer your way of doing it. Just take a look at Shareaza. They have to fix/improve eD2K support, BT support and G1 support. IMO it's better to have one network well supported and then starting to code the next module. Little fixes can be done later, sure, but not THAT BIG fixes. eD2K support in Shareaza before 2.1.0.0 was really horrible, and that was 2.1.0.0.horr
 
Post a Comment



<< Home

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