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

Tuesday, September 27, 2005

Designing Client Subsystem

It's becoming clear that the Client Subsystem will be the most important addition to the core since the original completition of the hncore API's; a LOT of code will be depending on this subsystem, so it's critical that it gets done right the first time, since writing it twice will take 5x the time (5 modules depending on it). Hence, I'm not rushing into coding it until I have a clear underastanding of the subsystems responsibilities, requirements and design.

The Client subsystem will be composed of two classes - BaseClient class, from which plugins shall derive their customized Client's, and ClientManager singleton, which will provide various lookups and views to the clients listing. Those two classes will need to serve three purposes:
  1. Reduce duplicate code over plugins in related topics, such as chunk requests for example.
  2. Provide information about clients to user interfaces
  3. Provide various views about the clients listing (possibly spanning tens of thousands of objects).
The first bullet wasn't originally planned for the subsystem, however as I realized that the same chunk-request generation code has been copied verbatim from ed2k to bt to http, it clearly shows this must be generalized. A4AF handling, chunkmaps and similar should also be centralized into this BaseClient class to further reduce duplicate code over modules.

The second bullet is generally const virtual methods, providing access to various client data, including nicknames, software, protocol and so on. Plugins shall simply override the virtual functions to return their information.

The third could be considered hardest to implement. It will need either multiple different containers, or single multi_index container for the various views; the views must be kept up2date (which might impose some limitations on the BaseClient class API). It must be possible to look up all clients for a specific download, all connected clients, all clients with specific client software, all clients which have requested a specific file and so on. This will allow lot of interesting and custom views that user interfaces can then implement. Also, it should be considered that the listing may contain tens of thousands of objects, hence any kind of looping on the listing is completely out of the question.

An iterator-based interface for the ClientManager class could be a nice and clean solution, however I'm slightly concerned that if I expose multi_index_container and the iterators in the public interface, some of the testers on slower machines will be unable to compile Hydranode anymore - we did run into similar issue some some 4 months ago, when I was using multi_index containers in many places and exposed them in header files - memory and time requirements during compilation skyrocketed. To add to the problem, the derived Client classes are most often the largest classes in the module (ed2k one is 2500 lines, bt is 800), and they usually include a large set of hnbase and hncore headers already)... Lately, I'v used wrapper iterators, (ed2k/downloadlist.h, DownloadList class), however this approach doesn't scale well. The alternative - using a combination of STL containers - is way too much of a nightmare - been there, done that, really don't want to go there anymore.

Edit: Actually, the above only affects ClientManager class, not BaseClient class; and ClientManager class will only be needed by ui modules (hnsh) and cgcomm module(s), so it's acceptable to expose multi_index_containers in the public API; BaseClient API will be very light-weight on the compiler/compile times.

Madcat, ZzZz



Comments:
Regarding your previous post... the udp:// is from the UDP-tracker protocol extension. Here are some links I managed to find on the subject:
http://libtorrent.sourceforge.net/udp_tracker_protocol.html
http://xbtt.sourceforge.net/udp_tracker_protocol.html

There also seems to be a UDP v2 protocol but I don't know if it's the same thing as this one. Azureus supports the one I mentioned above and I could find references to the v2 in the changelog so maybe they are one and the same or maybe Azureus just supports them both.

Also, another link which you may find helpful: http://wiki.theory.org/BitTorrentSpecification
 
About slow compiling and impossible on slow computers, don't worry about it. The important stuff is better development, faster app and constantly improving to being better all time. There can be internal builds for testers using slow computers (maybe autogenerated builds...) ;)

You are thinking in a very smart design, modularizing and reducing code in modules the most possible is the key to easier module development and more people coming to the project. Don't worry about doing unusable the HN code for some time if the final results will benefit in the near-medium future, remember this stuff is the most important and now is a lot easier to do than in matured development stages (never is late for doing it better, but better doing it sooner because it will be better and easier to do) ;)
 
Please consider doing an analisys again of all HN design, studying smarty a lot of different protocols of file transfering networks (a lot of p2p ones, irc, usenet...). After this, do a "conference" with all HN programmers about what to change and because why... Maybe you will be surprised after the results and solving most design problems in less time...
 
I agree with Anonymous Number 2.
After spending three days building HN on my box, months ago, I have never tried to build it again. I just wait until you post a new release on bytez.
In the future, I plan to build it again, but only when I upgrade my box.
 
Post a Comment



<< Home

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