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

Wednesday, October 05, 2005

Busy with hardware/software maintainance

People keep asking me - what am I doing? What am I working on? True, I returned on monday as scheduled, but there hasn't been much (any) activity on SVN since then; furthermore, there are some rather serious bugs open, inherent from the new ClientManager (it crashes rather often right now).

Basically, yesterday and today went to hardware and software maintainance on my development systems... defraging disks, re-organizing data, and it will be concluded tomorrow early morning by reinstall of one box (Ubuntu 5.10 preview, if anyone cares). Following that, I can resume normal development routine again, and first targets are fixing the bugs introduced by the ClientManager, moving statistics handling to ClientManager (currently handled inside ed2k module), and introducing generic upload-management (which brings BT to usable state - currently it cannot upload).

Meanwhile, I got some more ideas on two topics. First, in eMule (and some other clients), there's a concept called categories - you can assign downloads to categories, have separate incoming dirs for them, can pause/resume them separately etc; these are usually implemented in user interfaces via tabs or similar. However, in Hydranode, we will need an additional concept, which I currently call download groups. These could be implemented by user interfaces as "subdirs" in the listing. They differ from categories by two things - 1. they are created only programmatically, never by user, and 2., their names are usually long. Examples of such groups are torrents, and eMule / ShareAza Collections.

The second idea is related to core/gui comm. Namely, I figure that we will need to assign a unique identifier to each operation requested by user interface; when core responds to a command, it sends the original id back. This allows more flexible management on both sides, as well as cleans up the protocol somewhat. Also, on the hncgcomm library, it will need to be re-structured - currently it exposes too much of the underlying system. Basically, hncgcomm API should mirror core API - for example PartData object would have pause(), stop(), resume(), getSources() and simialar methods. The difference here, however, is that all operations are performed asyncronously, which is where the operation ID's come in - when GUI requests a download to be paused, the request is sent to core, and the response to the operation - either success or failure - is sent back, so GUI can react. The current protocol design doesn't allow that, so GUI would simply work "blindly".

Meanwhile, while I'v been pre-occupied with other things, wubbla has been busy improving the http module. Among major code cleanups and re-structurings, several new features have been added - automatic download mirror finding (via www.filemirrors.com), automatic hashes finding (sha1 and md5, and they are checked against when the download completes), and automatic .torrent file finding (and passing to BT plugin).

Madcat, ZzZz



Comments:
Regarding the categories, what I would like to see is a system that allows to control which files are downloaded / paused, etc. in a more automatic fashion than for example in eMule.
Imagine you have two series and some albums you want to download. You want a total of two files to be transferred at max., as to not cap upload too much. Ideally I would then be able to tell the application that there are my two shows, where the individual files will probably have the same sources, and my albums, where I don't really know about the sources. It then groups them (show1, show2, misc.) and only starts one file of each show (=better sources). In case one file is stale and we can't find any sources, the application should move on to the next episode or download one of the albums if there are no episodes anymore. After a while it could check the source status of the remaining episode (the one that was stalled the last time) and if there are sources now, we stop our album/whatever and resume the episode.
What I would like to achieve with this it that I don't have to do this myself and check my p2p app every few minutes. I could just queue up some files, leave it there over night and be sure that my bandwidth is maxed out. But well, maybe it's overkill...

Concerning cgcomm, that sounds very interesting. I know you said sth. about it not being possible to link HN as a shared lib but I just can't recall the reasons. Because if it was possible in some way we could create a wrapper that allows any GUI to seamlessly support a built-in and a remote installation of HN.

sca
 
Good news on cgcomm. This is the right decision (since the old was pretty wrong). I was thinking of implementing the protocol and the only thing to match request/responses asyncrhronously that came to my mind was some form of "expect" callback table. I.e. you issue a command and you register several callbacks for the possible responses. Pretty inefficient (too much branching).

Since you're at it why not also provide a operation_state facility. The GUI passes the id of the operation to the core to check on it's progress (in percentage or as a state). Useful for lengthy operations.
GC
 
Post a Comment



<< Home

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