this may have unintended consequences, as we need to deal with messages received from skewed clocks, but I believe the two pathways
used here are safe (we leave the larger timeout thresholds intact for dealing with remotely generated message times)
* revert some of the overly zealous peer distribution code - select randomly from the fast peers, not according to a strict LRU
(which was causing lots of queued up tunnel requests, as well as tunnel failures when they all failed)
need to think some more thunks about how to address this right now. a few different algorithms available
to deal with different scenarios and #s of users, but nothing that by itself strikes me as 'ideal', yet. perhaps its
time for another trip to the pub to see what inspiration can be found there ;)
* removed all of the "temporary" threads used for adding timeouts to blocking socket operations:
- use the ConnectionEstablisher's thread + a SimpleTimer.TimedEvent callback to timeout socket create
- added a pool of socket handler threads (size=3 atm) for receiving any inbound sockets, which are
pulled off a queue, after which a handshake occurs to verify the other side is I2NP (along side
another SimpleTimer.TimedEvent callback in case that blocks)
this should get the last of the temporary threads (Jetty has its own thread pool for dealing with
HTTP requests, so we can ignore that thread created in the AdminRunner). The only significant
reduction in threads left is to go with either NIO or UDP, but neither are happening in the immediate
future.
* use that to render the last few lines of the wrapper log on /logs.jsp (for the on demand stack trace)
* thread creation / finalization logging
* support a hard restart (stop immediately and restart the JVM) - useful for rerunning clients.config (etc)
* systray when not supported
* new safer way of shutting down the router per discussions with oOo (dealing with a graceful
shutdown where the user updates their config before the shutdown is complete, etc)
* graceful shutdown implemented in the router - shutdownGracefully(), cancelGracefulShutdown(), shutdownInProgress()
into account various skew situations and the capacity growth constant with
the intent of producing a higher quality threshold whenever possible
* increased the minimum # of fast peers from 4 to 8 (yay), which means we'll
try to have at least some peers to choose from
* added a new router config option - "router.maxParticipatingTunnels". This is
useful for gracefully shutting down the router (aka set it to 0 and wait until
the router is no longer participating in tunnels, then shutdown). You can
probably also come up with other situations where this is useful, but I don't
want to spoil all the fun ;)
reading the router's props only if that file doesn't exist.
* by default, only log CRIT messages to the screen (the rest are sent to
the log file). this will be useful with the upcoming service controller
* refactor a common Properties helper to DataHelper.loadProps
much of our tunnel failure detection code itself uses tunnels - send out tunnel 1
and get the reply through tunnel 2. If it fails, which one "broke"?
* we now add a failure mark to both in all situations, including during tunnel
creation
* properly check the tunnel expiration 2-2.5 minutes prior to completion, rather
than the old 0.5-1.5 minutes.
requests which are notified on completion
* query peers who are sending us bad references, just don't follow their suggestions.
this is necessary since the peer may actually have the data (and other people may not be
getting shitty references from them)
when picking peers to participate in a tunnel, we still select from the 'fast' tier,
except now we pick the ones that have least recently agreed to participate in a tunnel.
(they're already in the fast tier, so they're reliable [ish]).
the diversification has been pretty good so far, but i'm going to leave 'er running and monitor it overnight
(e.g. we can't find the referenced peer or the data they send back is corrupt/expired).
This is like the old invalidReplies, except its a rate that decays.
* if we receive more than 5 invalid replies from a peer in a 1-2 hour period,
stop verifying any subsequent replies, and also stop asking them for keys.
* cleaned up the store validation even further
* apply oOo's patch for beautifying the new console w/ links to a shitlisted peer's netDb entry
* apply oOo's patch to clean up the peer shitlist count more aggressively
* apply oOo's patch to allow removing lines via /configadvanced.jsp
* apply oOo's patch to clean up the memory usage display
* apply oOo's patch to include log messages on /logs.jsp most recent first, rather than last
* get rid of the netDb key shitlist (its a bad idea, better solution coming soon)
peers that we would crawl the entire netDb looking for (always failing, since there aren't any current
netDb entries for that peer that we would accept).
* keep a shitlist of keys we have recently searched for but were unable to find so we don't flood
* if our in-memory data store won't accept the data, its not helpful, so delete it on disk
* no need to do the preemptive refetching of a leaseSet, since we already garlic wrap it with payloads
* logging
> Message-ID: <1776.202.37.75.101.1092369510.squirrel@202.37.75.101>
> From: adam@adambuckley.net
> To: jrandom@i2p.net
>
> [...]
>
> I hereby authorize my NtpClient.java and NtpMessage.java code to be
> redistributed under the BSD license for the purpose of integration with
> the I2P project, providing that I am credited as the original author of
> the code.
>
> [...]
w00t! adam++
code migrated into core/java/src/net/i2p/time, integrated with Clock,
dropping that whole ugly pass-the-time-through-URL, and hence dropped
support for :7655/setTime.
New router.config properties to control the timestamper:
time.sntpServerList=pool.ntp.org,pool.ntp.org,pool.ntp.org
time.queryFrequencyMs=300000
time.disabled=false
So, to disable, add time.disabled=true to your router.config. It is
enabled by default.
Default router.config and startup scripts updated accordingly (since
timestamper.jar is now gone)
stack traces (rather than "oh, we're doing it when... uh... writing to the socket")
* increase the throttle max, since we want to be able to send a few concurrent
* detect situations where we may be inadvertantly flooding the netDb
and log them as CRIT with a stacktrace, as well as publish the count
of those events in the netDb
* detect potential netDb DoS situations by checking to see if we have
received more than 20 netDb lookups in 10 seconds, and if so,
probabalistically drop subsequent netDb messages (P=1-(10/numReceived)).
This is also published in the netDb.
