Some optimizations here, to keep cpu usage down ...
- [core] API addition: SSocket::getData() method, which returns the current input buffer, thus avoiding the (possibly costly) string::append() call, and performs only string copy (implicitly shared data on major implementations, so no data copying)
- [ed2k] Silently ignore few more race conditions which are inherent from remote clients sending packets in wrong/different orders.
- [ed2k] Added some early returns and misc optimizations to packet parser, to avoid unneccesery parse attempts for incomplete packets.
- [ed2k] Dropped -fomit-frame-pointer compile flag, since cryptopp breaks with it
- [ed2k] cryptopp code fixed to also compile with -pedantic flag (enforces strict ISO C++)
- [core/ed2k] Don't create random number generators in function scopes; the reason is that allocating rng's can be costly, and they perform better if they are not reallocated after each use.
The CryptoPP stuff is giving me headackes ... it's currently still spitting out hundreds of warnings when enabling -W -Wall ... but luckily, we have an alternative -
Botan. Fully featured, ISO C++, portable cryptographic functions library. Initial review of it showed it's exactly what we need - it's real nice, it's compact, nice API, etc ... in fact, I haven't found anything wrong with it yet ... sounds too good to be true ... but guess we'll find out soon enough.
Currently I'm trying to add
--with-[module]=[builtin|module] configure options, to allow compiling modules in, or as ... modules ... or not at all - just as linux kernel modules. Ran into some disagreements with autoconf on the topic, but I'm roughly half-way done by now ... I'm not sure how scalable autoconf will be for this situation - specifying
--with-[module]=builtin for ten modules and
--without-[module] for another ten modules can quickly get tiresome, but I guess we'll deal with that problem once we get there.
(Yes, I'v considered using linux kernel built system, and will re-consider it when we reach the amount of modules that autoconf is no longer scalable enough.)
On other news, theSilva reported successful hydranode compilation on P/100 (yes, 100mhz pentium), 64mb ram, running Slackware 9.1. The compile time was roughly 5 days, hydranode ran successfully. All hail the mighty pentium-100 ;)
For the record, chemical has been using HydraNode on his dual pentiumpro/200 for months now, and reports ~10% CPU usage with full debug/trace code enabled, so, while still needing some tweaking and optimizations, hydranode can be used on such low-end hardware.
Madcat, ZzZz
