* 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.
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?)
this stat is published in the netDb, but the quantity fields (how many acks the stat is averaged over) is h4x0red
(it always reads "666", since otherwise it'd be fairly easy to identify what routers run servers, and i can live without knowing the quantity)
(min/max frequency=1m/30m, doubling every time we don't find something new)
reduce the bredth and duration of explorations
republish less often (every 60s send out one random one [or however many explicit ones])
logging
new VMCommSystem (useful for running large multirouter instances)
new MultiRouterBuilder (helper app for setting up a MultiRouter simulator)
updates to the router to handle multiple routers in the same VM, as well as
deal with the multiple OOM listener stuff
see the javadocs for info on the MultiRouter and MutliRouterBuilder
(yeah, its not ready for prime time, and its really just for the simulator,
so I'm not sure if anyone else is going to use it anyway ;)
a rooted app context. The core itself has its own I2PAppContext
(see its javadoc for, uh, docs), and the router extends that to
expose the router's singletons. The main point of this is to
make it so that we can run multiple routers in the same JVM, even
to allow different apps in the same JVM to switch singleton
implementations (e.g. run some routers with one set of profile
calculators, and other routers with a different one).
There is still some work to be done regarding the actual boot up
of multiple routers in a JVM, as well as their configuration,
though the plan is to have the RouterContext override the
I2PAppContext's getProperty/getPropertyNames methods to read from
a config file (seperate ones per context) instead of using the
System.getProperty that the base I2PAppContext uses.
Once the multi-router is working, i'll shim in a VMCommSystem
that doesn't depend upon sockets or threads to read/write (and
that uses configurable message send delays / disconnects / etc,
perhaps using data from the routerContext.getProperty to drive it).
I could hold off until the sim is all working, but there's a
truckload of changes in here and I hate dealing with conflicts ;)
Everything works - I've been running 'er for a while and kicked
the tires a bit, but if you see something amiss, please let me
know.
if a client only wants 0 hop tunnels, give them 0 hop tunnels (rather than wasting a 2+ hop on it)
make inNetPool.dropped and inNetPool.duplicate rate stats, not frequency stats
formatting, minor refactoring
