jrandom authored 20 years ago and zzz committed 20 years ago

    * Allow peers on the same LAN to communicate with each other safely even
      when they cannot talk to each other through the external address.

jrandom authored 20 years ago and zzz committed 20 years ago

    * Display how much time is left before the graceful shutdown is complete.
    * Debug some improperly failed messages on timeout or disconnection.

jrandom authored 20 years ago and zzz committed 20 years ago

    * Don't go into a fast busy if an I2PTunnel 'server' is explicitly killed
      (thanks mule!)
    * Handle some more error conditions regarding abruptly closing sockets
      (thanks Jonva!)

jrandom authored 20 years ago and zzz committed 20 years ago

    * 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

jrandom authored 20 years ago and zzz committed 20 years ago

    * 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".

jrandom authored 20 years ago and zzz committed 20 years ago

    * Assure that we quickly fail messages bound for shitlisted peers.
    * Address a race on startup where the first peer contacted could hang the
      router (thanks Romster!)
    * Only whine about an intermittent inability to query the time server once

jrandom authored 20 years ago and zzz committed 20 years ago

    * Command line utility to verify a peer's reachability - simply run
      net.i2p.router.transport.tcp.ConnectionHandler hostname port# and it
      will print out whether that peer is reachable or not (using a simple
      verification handshake).

jrandom authored 20 years ago and zzz committed 20 years ago

    * Handle partial reseeds, caused by seeds going away before the download
      completes (thanks Sugadude!)

jrandom authored 20 years ago and zzz committed 20 years ago

    * Explicitly refuse IPv6 addresses, since only some peers support
      them and we want fully reachable peers.

jrandom authored 20 years ago and zzz committed 20 years ago

    * Additional error handling for a variety of transport layer errors.

jrandom authored 20 years ago and zzz committed 20 years ago

2004-09-30  jrandom
    * Bundle the configuration necessary to run an eepsite out of the box
      with Jetty - simply edit ./eepsite/docroot/index.html and give people
      the key listed on the I2PTunnel configuration page, and its up.
    * Router console cleanup, and some (off by default) tunnels -
      smtp.postman.i2p (port 7659), pop.postman.i2p (port 7660), and
      irc.baffled.i2p (port 7661)

jrandom authored 20 years ago and zzz committed 20 years ago

* deal with some degenerate situations with identities changing and auto IP detection
* some catch-alls for cleaning up the registry on degenerate tunnels
* lots of logging

jrandom authored 20 years ago and zzz committed 20 years ago

    * Bundle the configuration necessary to run an eepsite out of the box
      with Jetty - simply edit ./eepsite/docroot/index.html and give people
      the key listed on the I2PTunnel configuration page, and its up.
plus minor bugfixes / refactoring / logging

jrandom authored 20 years ago and zzz committed 20 years ago

- sendsPerFailure: how many partial sends we make when they all fail
- timeoutCongestionInbound: describes how much faster than our average speed we were receiving data when each partial send timed out (in Bps)
- timeoutCongestionMessage: our send processing time when each partial send timed out (in ms)
- timeoutCongestionTunnel: our tunnel test time when each partial send timed out (in ms)
- participatingMessagesProcessedActive: # of messages more than the (most recent) average that a tunnel we were participating in transmitted (for tunnels with more than the average)
* updated to use Writer for rendering the console, so we can do partial writes (and hopefully help debug some kooky threading bugs on kaffe)

jrandom authored 20 years ago and zzz committed 20 years ago

- sendsPerFailure: how many partial sends we make when they all fail
- timeoutCongestionInbound: describes how much faster than our average speed we were receiving data when each partial send timed out (in Bps)
- timeoutCongestionMessage: our send processing time when each partial send timed out (in ms)
- timeoutCongestionTunnel: our tunnel test time when each partial send timed out (in ms)
- participatingMessagesProcessedActive: # of messages more than the (most recent) average that a tunnel we were participating in transmitted (for tunnels with more than the average)
* updated to use Writer for rendering the console, so we can do partial writes (and hopefully help debug some kooky threading bugs on kaffe)

jrandom authored 20 years ago and zzz committed 20 years ago

    * Always wipe the Jetty work directory on startup, so that web updates
      are reflected immediately (Jetty does not honor the cache across
      multiple executions)
in addition, refactor various file ops out of the DataHelper into FileUtil

jrandom authored 20 years ago and zzz committed 20 years ago

got some pretty heavy GC churn when under load.  rough estimate is we allocate 5-8x as
much data as we need, copying it all over the place before forwarding it (or processing it).
this should cut down a few of those copies, but not enough yet.  it'd be great to get that
down to 2x.
* lots of logging

jrandom authored 20 years ago and zzz committed 20 years ago

let the algorithm handle writing the output to various places in the output array (so we can cut down on temporary memory allocation)

jrandom authored 20 years ago and zzz committed 20 years ago

* more defensive programming
* more javadoc updates