Update to 395. Still doesn't work for me.

395:

- Limit outgoing msgs according to available bandwidth. This means
that contrary to previous builds, which relied on socket buffers
becoming full and write()s going to block the code guesstimates
the time it takes for each message to go out, according to the
currently available bandwidth. This should reduce the lag of messages
and at the same time give a better picture for the queue size
calculations that have an influence on the routing of messages

- Rewrote the network functions inet_addr/inet_ntoa and ntohs/htons
into combined functions in src/sock.c - this simplifies the debug
code, which always had to call several functions to print an IP:port
- and it would/will make it easier to move the code to a different,
additional protocol in the future (like IPV6 or something entirely
different). Another reason for this was that I suspected some nodes
trying to exploit bugs in OS's network functions. I saw several IP
numbers with trailing blanks, or blanks after then numbers etc.
The code in sock.c is very rigorous about the format: if anything
is non-standard in a dotted quad IP number and/or port, the address
is considered invalid and the function calling it will fail. "No
grace" ;)

- Finn, a (new?) Entropy tester, found a resource leak in config.c
- the conf_update() function was not closing the file handle that
was used to change back to the previous working directory (or
current working directory). This would lead to "Out of file handles"
errors after some hours or days, depending how many file handles
were available to the user running Entropy.

394:

This one fixes a lot of flaws and bugs in string buffer handling
(look at the CVSweb history to see where they were). I found most
of the bugs after switching to the new, builtin (v)snprintf - after
fixing some bugs in the new code itself.

Some of bugs were more serious, such as a mismatch between array
size declaration and initialization in sha1.c

It looks like the code needs much more auditing to avoid this kind
of bugs, or at least find them and eliminate them at some point.

394 won't talk to nodes running builds prior to 393; please update
more often if you're still running 38x builds.

393:

?

392:

After observing my nodes for quite some time and looking at the
reasons why certain keys would never go out, I reworked the timing,
delays and retries, as well as a node's general responsiveness
(limiting of replies due the data store's fingerprint).

This build has a timing that more closely meets a node's available
bandwidths as the prior versions. The delays are based on the sizes
of keys, retry number etc.

With the few nodes that are running build 392 I can already see an
improvement, so you might want to upgrade, too

391:

And another stupid bug:  There was a cut and past bug in peer_adv_key().
I must've happened recently, and was definitely a show stopper.
The GLOBAL_LOCK was unlocked twice - fortunately the osd_sem_post()
function cancelled the double unlock, but the code was still wrong,
so there you go...

390:

It fixes two bugs in the crypto modules:  crypt3 was broken, because
decrypt_msg didn't increment the pt (plaintext) pointer. A lot of
the node ups/downs are due to nodes trying to contact each other
with crypt3, only to realize that they can't talk to each other.

crypt1 was broken, too, because the crypt1_next() function was not
incrementing the current index. I also changed the code that does
the "rotation" of the key and inlined it into crypt1_next(). The
module passes the diehard tests - I only ran a few, though.

The other change is about routing. A node's "destination fingerprint"
is modified so that it has 6 peaks instead of only 4. The "destination
fingerprint" is kept in the store/version file and is mixed to the
real fingerprint 50:50, so this change should make some nodes prefer
routes that were just under the limit before.

New stores will be created with a destination fingerprint with 6
peaks right from the start; nodes wit data stores that are almost
full will most likely see next to no change in the visible fingerprint,
or only a slow change over time. That doesn't hurt, as long as we
get a good average routing across all nodes.

entropy/Makefile

@@ -1,4 +1,4 @@
-# $NetBSD: Makefile,v 1.41 2003/12/18 14:45:02 tvierling Exp $
+# $NetBSD: Makefile,v 1.42 2003/12/27 15:59:50 thomasklausner Exp $
 #
 
 DISTNAME=		entropy-${ENTROPY_VERSION}
@@ -17,7 +17,7 @@ GNU_CONFIGURE=		yes
 USE_BUILDLINK2=		yes
 USE_GMAKE=		yes
 
-ENTROPY_VERSION=	0.7.2-388
+ENTROPY_VERSION=	0.7.2-395
 
 CONFIGURE_ARGS+=	--enable-verbose
 

entropy/distinfo

@@ -1,5 +1,5 @@
-$NetBSD: distinfo,v 1.42 2003/12/18 14:45:02 tvierling Exp $
+$NetBSD: distinfo,v 1.43 2003/12/27 15:59:50 thomasklausner Exp $
 
-SHA1 (entropy-0.7.2-388.tgz) = 51992eeac9e86efe9c7d621aae6e09991b6e0673
-Size (entropy-0.7.2-388.tgz) = 773189 bytes
+SHA1 (entropy-0.7.2-395.tgz) = 55bf1f3be0c065196dee37e2a8ef00f1df91729c
+Size (entropy-0.7.2-395.tgz) = 780045 bytes
 SHA1 (patch-ac) = 3651aec19ae8e079217121de231467a30fb1f73a