Main Page | Class Hierarchy | Data Structures | File List | Data Fields | Globals | Related Pages

Moonlight's Miscellaneous Code Snippets Collection (MCSC)

As I dig around eMule's source code to find inspiration for new coding concepts, snoop around to add support for personal tweaks and clean ways to add new features, I stumble upon various bits of "This could be [more] useful" code and this page is where I will paste these simple changes/additions.

Current snippets:

Warning:
All full files and code fragments are taken from Moonlight's Mod (Upcoming build: 0.42b-0.22g, 2004-03-03) and may contain changes unrelated to the ones enumerated here. For the newest complete source code files, download the zipped sources from Moonlight's Mod (Upcoming build: 0.42b-0.22g, 2004-03-03).

Global shutdown event

As eMule starts becomes increasingly more multithreaded, a more deterministic way of notifying sleeping threads (waking them up) is to use a global event and make the threads use a CMultiLock object, relying on the "Any Lock" wake-up of CMultiLock::Lock. Since ShutdownEvent is a 'manual' event, once signalled all threads waiting on it will wake up, detect the Shutdown lock and quit ASAP.

File Range Locking

I do not know if this bit of code has anything to do with it or if it is 0.30c, but I appear to be getting fewer (as in none so far) corrupt chunks since I began implementing this lock in a more proper manner. Maybe I am just luckier with my sources or the sources that used trashy clients have upgraded/fixed.
Since:
2003-11-06: Added a 'force' parameter fo FlushBuffer - to force flush during destruction: any block that fails destruction flush should be put back into the gap list, avoiding corruption due to thinking blocks were downloaded when they actually never got to the disk.

Moonlight's Guaranteed Minimum Download Slot Speed (MGMDSS, Experimental)

I wrote this from curiosity. I read some people complaining about how eMule lets download slots starve when previous download slots are using up all the download bandwidth and how this occasionally cause their clients to lose a download slot for a rare file. Since I only use eMule for rare files, I figured that if I help people get their rare files, it should eventually help me to get my own rare files. That's what Moonlight's Save Upload Queue Wait Time (MSUQWT, last updated: 2004-02-04) was all about and the code here is also in the same category. I often see failed upload sessions for rare files and I suppose these failed sessions are due to this issue. After digging in for a while, I decided that it would be worth a look and this is how these code changes came to be.

What it does: these code changes set aside 20% of your download bandwidth to be evenly distributed across all active download slots. It also splits up the download list into three priority bins to reduce list checking overhead. (A gain currently mostly offset by the cross-checking I put in there while I am not 100% certain everything is in there and in perfect working condition.)

Note:
eMule appears to have speed management issues with low download speed limits on fast networks (LAN) very similar to the ones it has at high speeds. In both cases, it causes it to drop connections for no apparent reasons. At low download speed limits, the senders have highly irregular transmission speed
For the source code files, download the newest source zip on the Moonlight's Mod (Upcoming build: 0.42b-0.22g, 2004-03-03) page.

Multiple Selection A4AF

When I select multiple files to "Switch sources to any other file", I typically do not want the sources to end up on any other file on which I used "Send to any other file". The stock 0.30c code does not have multiple-selection A4AF to begin with so here it is:

Hits since December 5, 2003:
Count.cgi?display=counter|df=vllmtqtwVL2.dat

Generated on Sun Mar 7 15:02:11 2004 for Moonlight's eMule Hacks by doxygen 1.3.4