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

Tuesday, September 20, 2005

Preparations for next feature-set

Blog entry posted on Sept/11 outlined a current TODO listing. Today, we'r near to completing that - PartialTorrent internals were redesigned few days ago, Chunk requests are re-arranged near the end of download (altough some optimizations could be made there), and today's latest addition is a generic SpeedMeter class, which hides the speed calculation behind an easy API. Interface, Implementation.

Now, before we can add the SpeedMeter to each and every socket (and there-of create a signals/slots system to connect socket speeds to files/clients/plugins), we need some optimizations at Scheduler to compensate for the added complexity. Two specific optimizations were made - UploadReq / DownloadReq objects (internal Scheduler objects) are now reused, instead of re-constructed during each request; and added clock_gettime() variant of Utils::getTick(), which seems to be slightly faster than raw gettimeofday() calls (on Unix).

The next steps now are to add the SpeedMeter to each socket, add signal getSpeed to PartData, SharedFile and ModuleBase classes, to which various sources connect the SpeedMeters. For example, Scheduler will be responsible for connecting all sockets belonging to a module to ModuleBase's getSpeed signal, downloading clients will be responsible for connecting their socket (while data transfer is in progress) to the corresponding PartData et al.

When that's done, we get to somewhat more complex area that's been ignored until now. Namely, Client management, and a generic interface for Upload management. Currently, clients and uploads are managed module-specifically, and they are not available for core/gui comm module. What we need is a ClientList API at core lib, which will make the clients data available for user interfaces. If developed properly, it could (perhaps) also implement some kind of support for upload management (at least simplify/generalize it). Because, for example, the current ed2k upload management is quite a mess, and I don't want to create another such mess at BT module.

On related news, I added support for filerating tag support in ed2k searchresults (lugdunum 17.6 feature, will be included in eMule 0.46d probably). The value is integer, and my tests showed it ranging from 0 to over 1000, so it's yet unknown how to interpret the value properly. But guess we'll see, as soon as eMule 46d is released - for now, I'm just displaying it in hnshell as raw integer.

Other miscellaneus changes tonight include StopWatch::reset() method, addition of current ID to ed2k/serverlist/stat command, and fixed asking for sources on newly-added downloads (got broken few days ago with the pausing/stopping patch).

Madcat, ZzZz

Comments: Post a Comment

<< Home

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