On Fri, Apr 27, 2001 at 03:43:28PM -0500, Steven Hazel wrote:
> "Kalle A. Sandstr\"om" <[EMAIL PROTECTED]> writes:
>
> > Hm. I'll look into it. I think that libfreenet requires some cleaning
> > up, though... (frex, you're using floats to handle major.minor version
> > number pairs. ick.)
>
> Yeah, it definitely does need some clean-up. I've got an enormous
> list, and I'm working on it.
Is that a long list of small things or a small list of large things?-)
Anyway, mind passing the list my way? Maybe I could fix some of the
things while fleshing out the libfreenet integration.
> > Also, I'm not quite happy with some of the exported symbol names in
> > libfreenet, but I'm sure that can be remedied somehow :-)
>
> What don't you like? API criticisms are highly appreciated.
Many functions aren't prefixed (inappropriate for a potentially shared
library). The "freenet_get_connection" fn is too one-shot (a proper
node would have a thread run an accept(2) loop and pass the connected
socket fds to a peer handler). I'm sure there are others too :-)
> > If you don't have anything in particular against glib-1.2, perhaps
> > we could migrate some of the better bits in reiska to libfreenet?
>
> What do you gain by using glib-1.2? I don't know if I want to have
> the dependency.
Data structures. One thing that I've learned from C++ is that reusable
data structures are a Good Thing.
Also, glib has a nice stdout/stderr/logging abstraction which should make
things easier for a node that runs as a UNIX daemon (i.e. the node could
install its own log handlers into glib and push the output into a log file
instead of a stdout connected to /dev/null).
There's also a pretty nice mutual exclusion thingy in the glib thread
module, that would remove the need to code for POSIX threads if libfreenet
ever requires explicit threading support (gethostbyname(3), anybody?).
> > Particularly I'd like to see the message handling stuff in
> > message.[ch] get in libfreenet... perhaps the cipher stream
> > abstraction layer, too.
>
> I'll take a look at this stuff. libfreenet has its own message
> handling and cipher stream abstraction. Both need a little bit of
> work, but I'm pretty committed to their design.
My 'message_t' design was pretty far a reimplementation of the simple
HTTP server class I did in C++ a couple of weeks ago. That one used a
std::hash_map<std::string, std::string> to keep both the request and reply
headers in a request structure, which was then passed on to a virtual
function that was supposed to handle the request. The design worked pretty
well (apart from the fact that it allocated a pile of memory chunks for
each request) and I decided to use a same kind of 'fields in a mapping'
approach for this.
The 'cipherstream_t' stuff was designed to use a separate 'cipher_t' block
cipher encapsulation because I wanted to be able to switch between
Rijndael and Twofish cleanly, perhaps supporting other types of encryption
in the future. The result is a bit C++-ish, only in C.
> > I've also implemented the make_freenet_key() aka keygen() function
> > which you have limited to 20-byte keys.
>
> Cool, thanks. That was on my TODO list, as a nitpick. (We never
> actually use keys larger than 20 bytes in Freenet, and if we did, we
> probably would want to switch to a larger hash rather than rely on the
> key generation algorithm, but hey, it's nice to be compliant.)
Heh. It's really more of a translation of one of the Util.makeKey
functions in Fred than an independent implementation based on the (outdated)
protocol spec.
--
Kalle A. Sandstro"m ksandstr &at& iki &dot& fi
http ohutsuoli 2*viilto www piste iki piste fi viilto mato ksandstr viilto
1ED7 C636: 7728 49D5 F784 D2DD D20F 63CF 655D F19E 1ED7 C636
PGP signature
