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, February 21, 2006

Miscellaneous things

The report of the memory leak with MSVC8 caused quite some interest in Boost.Dev list; DateTime library was patched to work around this bug, but numerous other libraries are also affected by this, notably lexical_cast and program_options. Since patching MSVC CRT requires rebuilding the DLL, it's easier / more convenient to patch Boost libraries instead for the time being, until Microsoft releases official update. Considering that Boost 1.34 is expected to be released within a month, hopefully all the issues will be cleared up by then.

I discovered an issue in Utils::getFileSize() method which reported wrong size on Windows when the file size exceeded 4gb. The issue was usage of stat() method, which uses 64bit offsets on Unix when _FILE_OFFSET_BITS is defined as 64, but was using 32bit offsets on Windows. The fix was to use _stat64 on Windows. This bug caused all Bittorrent downloads which included files of size >4gb to become auto-paused with message 'out of disk space'.

I have also been working on thread-safe version of SharedFile::read(). The issue there is that when completing file, the file is moved from temp to incoming, and read operations while moving is in progress, or after the moving has been finished, but SharedFile::m_location hasn't been updated yet, fail, causing the SharedFile object to be destroyed, which under some circumstances can lead to crashes in hncore/bt/files.cpp. The solution was to use boost::recursive_mutex::scoped_try_lock in SharedFile::read() (try-lock so as to not block the main thread), and scoped_lock in MoveWork::process to syncronize the operations and throw E_TRYAGAIN error from SharedFile::read() in this scenario. Plugins handle this exception and re-try reading from the file in a few seconds. However, since the code hasn't been fully tested yet, it's not in SVN (not that SVN would be up, anyhow).

Last night I spent about 6 hours with our designer, working on icons for the GUI. So far, the results are 5 black&white base shapes, onto which we hope to add some style and effects tonight.

The 'zombie' clients count reported by 'ed2k deadsource' command was somewhat off originally, displaying too large (up to 60%) amount of 'zombie' clients. Largely, those were false positives, the m_lastAsked variable wasn't updated in all situations. After fixing that variable, I'm seeing around 10% of dead sources (272 out of 2351), which is more realistic. The most common cause for clients to become 'zombie' is that the connection is cut some time during handshaking, and we don't handle all these situations gracefully yet. Due to the large amount of time required to test and analyze these clients (1-2h runtime is minimum required for them to show up in the first place), this is very time-consuming process.

More on the GUI side - I managed to cut 8 pixels from each side of the GUI, winning total of 16px space in width and height. We also tested (for a moment) 24x24px icons on toolbar, but discarded the idea quickly - this interface seems to be heading towards very compact, spartan interface, where every pixel is carefully considered, and wasting 8px height just to have larger icons doesn't sound like good use for space. It's also expected that the filter-box on top-right will disappear after-all, and become more like firefox's "find-as-you-type" feature, since the practical usefulness of the filtering is near-zero, but it should exist nonetheless.


The filterbox has about the same value that the firefox search has. You could implement it even in a similar way. CTRL+F for filter and the filterbox opens up, like the search, then type as you filter. Closing the box resets the filter.

The alternative is to make it "search", as in find the first entry in the list that matches. With the needed function of find next (F3). I am more for a filter, works better in this scenario.
now that razorback2 is down perhaps supporting the Kad Network should be a higher priority
Yes, decentralized (and anonymous) p2p networks are the future.
razorback is down but there are tons of other server out there.
Currently kad2 is developed and there is no sense in developing kad1 support.
I agree about decentralized being the future
I really do not know what directions should we take in network-sharing development. Just wait some days and let things calm down, sure there is something else to do.
About Kad2.0:

It seems an improvement of the original Kad1.0, not a rewrite, so seems feasible to implementing Kad1.0 because probably a lot of the code will can be reused for Kad2.0 (the magic of C++).

Any volunteer? Still isn't possible to clone Madcat! :(
Not forget that Kad2.0 seems a very long term project, even more probably because it seems only one developer (Unk) is developing it.

I hope they add full anonymous support (ants p2p, MUTE...) and half-darknet style (like an obligatory cache of encrypted data that is shared, the user will not have problems with 1GB of encrypted share cache and the network will run a lot better.
1. What's new in Azureus

1.1 Encrypted/Obfuscated Data Transfer
Support for encrypting the data between Azureus and other compatible clients is included. This both provides a level of protection of data and can help with ISPs that block or restrict peer-to-peer traffic.

1.2 High Speed LAN Transfers
Multiple copies of Azureus running on the same local network support high speed direct connections.

1.3 Improved Download Algorithm
The algorithm used to determine which pieces of a download to request from which peers has been rewritten to improve its behaviour and performance.

1.4 Webseed Support
Basic webseed support is included. Webseeds will only be used when a download's availability is less than 1.0.
Regarding end-to-end encryption:

This is really pointless.

"I hope they add full anonymous support [...]"

Kad 2.0 won't be anonymous. It's just Kad (1.0) with more features, but not such massive changes.
More details about Kad 2.0 can be found in Developement-Subforum in eMule-forums.

Creating a Kad 1.0 module now won't be a big mistake, since Kad 2.0 will be backwards compatible.

But since Cyberz has no time to go on developing Kad module, maybe Madcat is going to finish his work, when he's done with GUI. I think that eMule v0.50 will be released then (with Kad 2.0; don't you think it will be called v0.50? ;) ).
That's too bad, I can't understand why non-anonymous networks are still in development...
"That's too bad, I can't understand why non-anonymous networks are still in development..."

Anonymous networks are slower than non-anonymous ones. Everyone needs faster upload rates, to assure reliable speed on anonymous networks. As long as they are slow, "the big mass" is not going to use them.

If I'm wrong, please tell me a total anonymous network which offers at least some stuff (I do not expect the amount of availabe stuff as it's in eDonkey2000)
End to end encryption is useless because copyright authorities normally act as normal clients that download from you and then log your IP adress. If you want to avoid that, you'll need a network that uses every user as proxy, but that would lower transfer speeds dramatically.
The best anonimity is gained in great masses.

The goal of end-to-end encryption is not to potentiate anonymity.
Post a Comment

<< Home

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