- May 07, 2004
-
- May 06, 2004
-
- May 05, 2004
-
-
* netDb.failedPeers (how many peers didn't reply to a lookup in time) * netDb.searchCount (how many searches we send out in a 3 hour period) probabalistically include the leaseSet of the sender in the garlic sent to a peer if the client requests it to be included (aka if they want replies). By default, this is enabled (disable by setting the I2CP prop "shouldBundleReplyInfo=false"). Also, by default the probability is 30% (w00 h00, arbitrary values!), which can be overridden via the I2CP prop "bundleReplyInfoProbability=80" (or =10, or =100, etc). The tradeoff here is quicker replies in exchange for bandwidth (the dbStore). Yeah, it'd be nice if there were something keeping track of which leaseSet each client sent to each peer so that it could explicitly include it only if it were necessary, but for now that's probably overkill.
- May 04, 2004
-
- May 03, 2004
-
-
* don't create excess I2PAppContexts (if any old context will do, use the global) keep track of keys per spec (when DESTINATION=blah, create (or reuse) the destination private keys). we still need to persist this data though. * the DESTINATION in the SESSION STATUS is now the same as the one sent in the SESSION CREATE, /not/ the base64 of the private key, per spec * enum is a reserved word in 1.5, so s/enum/names/ for future compatability * logging
-
removed nested synchronization (which had been causing undetected deadlocks) made sync blocks smaller, though this may have opened holes related to resent ACK/SYN/CLOSE packets that are delivered in a race. I'm not as fluent in the ministreaming lib code as i should be (yet), but duck's thread dumps were showing hundreds of threads waiting on a lock that'll never get released (since the only way to release it would be to receive another packet, and no more packets can be received until the lock is released, etc) also, I2PSession is threadsafe - i can see no reason to synchronize on it (and it was being synchronized on only part of the time?) also, refactored the charset encoding stuff and minor log tweaking i've been testing this for the last hour or so, on eepsites and squid (large and small files), as well as irc, and there haven't been any glitches. but it needs more testing before it can be released, obviously.
-
- May 02, 2004
-
-
fire the LoadClientAppsJob right after the admin listener is booted, which now includes support for the onBoot property (which causes the client to run immediately, instead of waiting 2+ minutes) (yeah, it'd suck if all routers started up, tried to connect to people, got shitlisted, then 2 minutes later got the right NTP time, 'eh?)