* Run the peer profile coalescing/reorganization outside the job queue
(on one of the timers), to cut down on some job queue congestion. Also,
trim old profiles while running, not just when starting up.
* Slightly more sane intra-floodfill-node netDb activity (only flood new
entries)
* Workaround in the I2PTunnelHTTPServer for some bad requests (though the
source of the bug is not yet addressed)
* Better I2PSnark reconnection handling
* Further cleanup in the new tunnel build process
* Make sure we expire old participants properly
* Remove much of the transient overload throttling (it wasn't using a good
metric)
* Bugfix for the auto-update code to handle different usage patterns
* Decreased the addressbook recheck frequency to once every 12 hours
instead of hourly.
* Handle dynamically changing the HMAC size (again, unless your nym is
toad or jrandom, ignore this ;)
* Cleaned up some synchronization/locking code
* Catch errors with corrupt tunnel messages more gracefully (no need to
kill the thread and cause an OOM...)
* Don't skip shitlisted peers for netDb store messages, as they aren't
necessarily shitlisted by other people (though they probably are).
* Adjust the netDb store per-peer timeout based on each particular peer's
profile (timeout = 4x their average netDb store response time)
* Don't republish leaseSets to *failed* peers - send them to peers who
replied but just didn't know the value.
* Set a 5 second timeout on the I2PTunnelHTTPServer reading the client's
HTTP headers, rather than blocking indefinitely. HTTP headers should be
sent entirely within the first streaming packet anyway, so this won't be
a problem.
* Don't use the I2PTunnel*Server handler thread pool by default, as it may
prevent any clients from accessing the server if the handlers get
blocked by the streaming lib or other issues.
* Don't overwrite a known status (OK/ERR-Reject/ERR-SymmetricNAT) with
Unknown.
* Further preparation for removing I2CP crypto
* Added some validation to the DH key agreement (thanks $anon)
* Validate tunnel data message expirations (though not really a problem,
since tunnels expire)
* Minor PRNG threading cleanup
* Within the tunnel, use xor(IV, msg[0:16]) as the flag to detect dups,
rather than the IV by itself, preventing an attack that would let
colluding internal adversaries tag a message to determine that they are
in the same tunnel. Thanks dvorak for the catch!
* Drop long inactive profiles on startup and shutdown
* /configstats.jsp: web interface to pick what stats to log
* Deliver more session tags to account for wider window sizes
* Cache some intermediate values in our HMACSHA256 and BC's HMAC
* Track the client send rate (stream.sendBps and client.sendBpsRaw)
* UrlLauncher: adjust the browser selection order
* I2PAppContext: hooks for dummy HMACSHA256 and a weak PRNG
* StreamSinkClient: add support for sending an unlimited amount of data
* Migrate the tests out of the default build jars
2005-06-22 Comwiz
* Migrate the core tests to junit
* Only build new extra tunnels on failure if we don't have enough
* Fix a fencepost in the tunnel building so that e.g. a variance of
2 means +/- 2, not +/- 1 (thanks dm!)
* Avoid an NPE on client disconnect
* Never select a shitlisted peer to participate in a tunnel
* Have netDb store messages timeout after 10s, not the full 60s (duh)
* Keep session tags around for a little longer, just in case (grr)
* Cleaned up some closing event issues on the streaming lib
* Stop bundling the jetty 5.1.2 and updated wrapper.config in the update
so that 0.4.* users will need to do a clean install, but we don't need
to shove an additional 2MB in each update to those already on 0.5.
* Imported the susimail css (oops, thanks susi!)
* Update the shitlist to reject a peer for an exponentially increasing
period of time (with an upper bounds of an hour).
* Various minor stat and debugging fixes
* Add a new stat logging component to optionally dump the raw stats to
disk as they are generated, rather than rely upon the summarized data.
By default, this is off, but the router property "stat.logFilters" can
be set to a comma delimited list of stats (e.g. "client.sendAckTime")
which will be written to the file "stats.log" (or whatever the property
"stat.logFile" is set to). This can also log profile related stats,
such as "dbResponseTime" or "tunnelTestResponseTime".
I marked all the empty statements with //nop
I removed unneccessary elses (ie, the if returns or throws)
I took out some casts (integral promotions/some didn't need to be there)
-- Love, shendaras
(2 in one day, w00t)
* rather than have all jobs created hooked into the clock for offset updates, have the jobQueue stay hooked up and update any active jobs accordingly (killing a memory leak of a JobTiming objects - one per job)
* dont go totally insane during shutdown and log like mad (though the clientApp things still log like mad, since they don't know the router is going down)
* adjust memory buffer sizes based on real world values so we don't have to expand/contract a lot
* dont display things that are completely useless (who cares what the first 32 bytes of a public key are?)
* reduce temporary object creation
* use more efficient collections at times
* on shutdown, log some state information (ready/timed jobs, pending messages, etc)
* explicit GC every 10 jobs. yeah, not efficient, but just for now we'll keep 'er in there
* only reread the router config file if it changes (duh)
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.
