jrandom authored 20 years ago and zzz committed 20 years ago

also link to the i2ptunnel from the top nav (in a new window).

jrandom authored 20 years ago and zzz committed 20 years ago

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

jrandom authored 20 years ago and zzz committed 20 years ago

the /i2ptunnel/ page so they can easily be shared.
* By default, try to create any needed private key files (for server tunnels only)
* keep track of the I2PSession objects used by the I2PTunnel instances (only needed
for exposing the associated Destination)

hypercubus authored 20 years ago and zzz committed 20 years ago

* service wrapper fully functioning under Linux and WinXP, should also be working for the other *nix platforms but this isn't tested yet
* renaming wrapper binaries to 'i2psvc' for *nix and 'I2Psvc.exe' for win32

hypercubus authored 20 years ago and zzz committed 20 years ago

moving standalone-compiler.jar into the izpack subdir

jrandom authored 20 years ago and zzz committed 20 years ago

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.

jrandom authored 20 years ago and zzz committed 20 years ago

oops, we need to mark the peer we don't send to as failed (otherwise we wont send any more requests out, since there will be 'too many pending')

jrandom authored 20 years ago and zzz committed 20 years ago

don't do the netDb store of the peer's routerInfo until after we validate what they tell us (so we can shitlist them for the right reason) [thanks duck!]

jrandom authored 20 years ago and zzz committed 20 years ago

handle a situation that would otherwise cause a search to block indefinitely rather than complete properly

jrandom authored 20 years ago and zzz committed 20 years ago

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)

jrandom authored 20 years ago and zzz committed 20 years ago

* expose the reason for a dbStore rejection more cleanly

jrandom authored 20 years ago and zzz committed 20 years ago

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

jrandom authored 20 years ago and zzz committed 20 years ago

(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

jrandom authored 20 years ago and zzz committed 20 years ago

* 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)

aum authored 20 years ago and zzz committed 20 years ago

wonderful Leo structural literate editor

aum authored 20 years ago and zzz committed 20 years ago

might not work yet for files > 28k

jrandom authored 20 years ago and zzz committed 20 years ago

more zealous bc synchronization
make sure we always close the streams explicitly
logging

jrandom authored 20 years ago and zzz committed 20 years ago

more carefully retrieve a proxy
logging (w/ unique requestId)