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, October 13, 2005

Keeping BT module class hierarchy simple

The next logical step now is to add proper downloads resuming and partial torrent handling (where some files are missing), as we now have the neccesery backends for that. But first, let's simplify the BT module class system slightly.

One idea when implementing the cache manager last night was also to put it into separate class, as yet another abstraction, however it turned out it was much better to merge it directly into the virtual files layer (which is an abstraction on it's own already). Same pattern should be applied to two more, already existing classes in BT module - Manager, and the newly-added TorrentDb. Neither of them have any big responsibilities that would justify having them as separate Singletons - TorrentDb just contains a map of torrents found in cache folder, and Manager basically just controls the listening port, and currently active torrents. Both of those classes should be moved to the BitTorrent class (the module's main class, derived from ModuleBase).

Once that's done, we can add a nice and clean loop in BitTorrent class, which loops over shared files, checks if it has any torrent associations (via metadata->customdata field), creates the torrent (if it doesn't exist), or attaches the file to existing torrent.

With this in place, the overall bt module class system stays within the original design graph - the addition of TorrentDb and BitTorrent classes broke away from that design, which causes unnecesery amount of files/classes in the module.

Madcat, ZzZz



Comments:
Does this support downloading a single file from both bittorrent and edonkey at the same time? (which is the whole point of the core I presume)
 
What about assigning priorities to each file separately?

About next network implemented... What about Ares and DC++? And usenet?
 
"Does this support downloading a single file from both bittorrent and edonkey at the same time? (which is the whole point of the core I presume)"

Yes

"What about assigning priorities to each file separately?"

Each file is handled as a separate download at core level, so all normal operations are allowed for each single file in the torrent, including pausing, canceling, resuming, and ofcourse, setting priorities (altough currently, hydranode doesn't support downlaod priorities).

"About next network implemented... What about Ares and DC++? And usenet?"

It's a bit early to think about that right now, considering that BT still needs a lot of work, we'r missing peer exchange, and DHT. However, the next network, once we get there, will be one of the mp3-nets - whether it'll be ares or Gnutella or something else is still open. Most likely path is that we focus on user interface for a while after BT, and then (or at same time) implement one of the mp3-nets.

Madcat.
 
Ares has many things in common with Gnutella, so probably implementing one could make a lot easier implementing the other (remember about the benefits of C++ ;))

http://www.answers.com/topic/ares-galaxy
" Because Ares and Gnutella both use the same hash function to uniquely identify files and giFT can also connect to the Gnutella network, giFT users operating both plug-ins can swarm downloads from both networks simultaneously."
 
Personally, I think is too early to focus on user interface, the next networks will change a lot many aspects of user interface design. I think it's better implementing several more networks before focus on user interface, then there will be a very different background of networks for developing a really flexible and thinked for the future GUI ;)
 
"Personally, I think is too early to focus on user interface, the next networks will change a lot many aspects of user interface design."

Yes, I agree. I think there should be another "searchable" network (and I prefer Gnutella since it offers many files + fast downloads), because designing a search window with only one "searchable" network could make things difficult for future.

But on the other side: many people avoid an application without graphical user interface (especial windows users).
 
Please not think that is more important to have more users using hn, fist is more important other design issues, in the start users isn't the most important thing in this kind of ambitious projects. And more networks supported will help even more to having more interested users after having a usable GUI...

My idea is:

* Perfecting internal design all time. Think about not only doings things running the best possible all time (that is very important) but doing easier the development of the project and understanding of the source code at same time, I mean really proffesional & extremelly correct coding. This will attract a lot of developers interested in P2P development. It's needed too being too careful about the code quality, a lot of projects has a bad code quality with the time (and started with incredibly great code).
* Implementing am important number of technically very different networks and think widely open about implementing more networks (not only thinking about users quote, but technological interest too...).
* Provide extensive documentation, both in separate correctly explained technical (and less technical) documents and source code. Improving documentation all time but remembering is more important quality than quantity.
* Designing heavily thinked UIs (http/wml, GUI...), not only copying the look'n'feel of others, but thinking of original ideas and doing easier the use of those programs, even for newbies to experienced users (easy to use, easy to configure, and easy to configure in a expert manner too).
 
" Please not think that is more important to have more users using hn [...]"

More users means more opinions on new ideas/existing features. More users means more feedback! That's very important IMO.
Sure, there shouldn't be made a kludgy GUI just to get more users.
 
"Does this support downloading a single file from both bittorrent and edonkey at the same time? (which is the whole point of the core I presume)"

"Yes"


How does this work? If I download a file from edonkey (FILEX), but a torrent is offering BIGFILE which happens to contain FILEX within it in a subdirectory, what type of verification is there that it is the same file? Can the user force it to be recognized as the same file (same size I guess)?
 
File size, or user forcing it, is not sufficient to allow such downloading, since both can be faked / be wrong. Only basis on which such multi-net downloads are allowed is when hashes match (for example, if torrent has ed2k hashes in it, then we can say for sure that it's the same file).

Aquiring those hashes for multiple networks is tricky, but the solutions have been designed over a year ago on how to do it - all that we need right now is more networks support (including finishing BT), so we can put that design to work eventually.

Madcat.
 
Post a Comment



<< Home

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