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

Sunday, December 04, 2005

Bittorrent things and MSVC support

10 years it was - "Every piece of software evolves until it can read e-mail."
Today it is - "Every P2P client evolves until it can connect to IRC."
- Madcat

Seriously though - looking how many P2P clients out there have IRC support, how many of them actually have a decent IRC support? Or, while we'r at the topic, how many multi-network IM clients have IRC module, and how many of them actually work? Or, while we'r on the topic, how many BT clients are out there, and how many of them actually work?

I was hanging in #azureus channel today, getting some intel [sic] about Bittorrent protocol and such. In particular, I was looking for info on the 'key' parameter in tracker communication, which was apparently needed by some trackers. It's used to keep track of clients after IP changes, and works somewhat similarly to ed2k userhash, except that it should be re-generated every startup. This is now properly supported in Hydranode. Another thing that came up during discussion was that it's required by Bittorrent netiquette to cap download-rate at 2xuploadrate when upload speed limit is less than 5kb. This is quite similar to ed2k netiquette, so implementing this was trivial.

Yet another interesting thing that came up during discussion was that there are actually more bad BT clients out there than there are good ones. And of-course, it was mentioned that BT support in multi-network applications is notoriously bad - mldonkey and shareaza being examples of that. Ohwell, yet another challenge for Hydranode to prove - that it's actually possible to have good BT implementation in multi-net client. Personally, I think it's doable, but it won't be easy. We still have quite a bit of issues to be resolved before Hydranode's BT implementation can be considered anywhere near good.

I'v been playing around with various versions of MSVC past few days, attempting to restore full MSVC compatibility in Hydranode code. The actual problems were rather trivial, some missing DLLEXPORTS here and some overloaded functions that confused the crap out of MSVC; at the end of the day, I can conclude that we have full compatibility with MSVC.NET 2003, mostly-compatible with MSVC Toolkit 2003 (free commandline tools), and mostly-compatible with MSVC 2005. The problem with MSVC Toolkit is that it lacks some combinations of runtime libraries, namely multi-threaded debug dll, and some more, so we must use explicit runtime-link=static runtime-debugging=off when building with that. As for MSVC 2005, it has introduced DLL versioning, and enforces it quite aggressivly, but I don't know enough yet about the topic to be able to implement the support. Btw, MSVC 2005 is also doing rather aggressive security checking on the code, but that triggers on a lot of valid Hydranode and Boost code as well, and as Boost people generally recommend turning that stuff off, so I did.

There were several reasons for restoring MSVC compatibility. For one, windows people expect to use MSVC for plugin-development and such; secondly, MSVC generates, on average, 4 times smaller code than GCC, and compile times are considerably faster (even without using precompiled headers). The main issue with mingw-gcc is link times, linking hydranode dlls or modules (average 100mb object files and 70mb final dll in debug build) took about a minute with mingw-gcc, but 7 seconds with MSVC. On Linux, it also takes roughly 7 seconds to link that, so it's clearly a mingw-gcc-specific issue. Another thing that MSVC seems good about is release-compilation - 14 minutes, which is roughly same as in debug build; release builds on gcc/linux are well over 20 minutes. In any case, getting Hydranode installed size from 15.0MB to 4.4MB, and installer size from 3MB to 960kb is pretty nice. Memory usage in release build dropped about ten times, from 13MB to 1.3MB, and from the looks of it, it's no longer using any CPU at all. This is what you get for developing on a slow compiler/platform for 1.5 years, and then recompiling the thing with a "real" compiler :)

Madcat, ZzZz

Edit: The memory usage didn't drop ten times, but only about two times. Looking at task-manager while half-asleep isn't such a good idea after-all. Sorry for the confusion.



Comments:
speed limits will simply encourage the creation of hydranode mods without the speed limits

software that can be run headless on clients working 24/7 has less of a need to speed limit as it shares for longer time unlike gui bound clients which are not left running overnight
 
That's a point.
 
IMHO MSVC is essential. I hate gcc for it's speed :) Apart from precompiled headers (big boost) incremental linking is what really makes the difference. I'm a "change a line-hit build-let the compiler complain" type of person and gcc really depresses me :)

BTW I've managed to create an Eclipse+CDT enviroinment for hydranode (real easy but a few gotchas). Using bjam as custom build tool it's just a drop the svn tree thing. Big advantage - GUI gdb debugging in the ide with all goodies - breakpoints, watches. Now I'll be doing the same with Code::Blocks which supports similar functionality. I can write a wiki page explaining how to do this stuff if someone is interested and can't get going.
GC
 
I guess one could copy the missing dlls for MSVC Toolkit from a Visual Studio installation... and make it available to others...
 
That would probably also be illegal, as you would need the .lib files. Microsoft didn't include them for a reason. If you were going to all that trouble, you could always more easily copy the whole of MSVC, but noone is suggesting that.
 
"it's no longer using any CPU at all"

what? i can't anylonger complain about Microsoft doing horrible software?

no more imperialist word against the big evil redmond company?:(

Just kidding of course :)
i'm a VS lover :)
and the only real reason of my Windows addiction!

if VS will jump from the bridge i guess i will follow very soon O:)
 
I forgot to ask, but is the
"it's no longer using any CPU at all"
still valid after u read the taskmanager full awake? :)
 
Post a Comment



<< Home

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