* Moved the current net's reseed URL to a different location than where
the old net looks (dev.i2p.net/i2pdb2/ vs .../i2pdb/)
* More aggressively expire inbound messages (on receive, not just on send)
* Add in a hook for breaking backwards compatibility in the SSU wire
protocol directly by including a version as part of the handshake. The
version is currently set to 0, however, so the wire protocol from this
build is compatible with all earlier SSU implementations.
* Increased the number of complete message readers, cutting down
substantially on the delay processing inbound messages.
* Delete the message history file on startup
* Reworked the restart/shutdown display on the console (thanks bd_!)
* First pass of the new tunnel creation crypto, specified in the new
router/doc/tunnel-alt-creation.html (referenced in the current
router/doc/tunnel-alt.html). It isn't actually used anywhere yet, other
than in the test code, but the code verifies the technical viability, so
further scrutiny would be warranted.
* Test the router's reachability earlier and more aggressively
* Use the low level bandwidth limiter's rates for the router console, and
if the router has net.i2p.router.transport.FIFOBandwidthLimiter=INFO in
the logger config, keep track of the 1 second transfer rates as the stat
'bw.sendBps1s' and 'bw.recvBps1s', allowing closer monitoring of burst
behavior.
* Added preliminary support for NAT hole punching through SSU introducers
* Honor peer test results from peers that we have an SSU session with if
those sessions are idle for 3 minutes or more.
* Revise the SSU peer testing protocol so that Bob verifies Charlie's
viability before agreeing to Alice's request. This doesn't work with
older SSU peer test builds, but is backwards compatible (older nodes
won't ask newer nodes to participate in tests, and newer nodes won't
ask older nodes to either).
2005-07-27 jrandom
* Enabled SSU as the default top priority transport, adjusting the
config.jsp page accordingly.
* Add verification fields to the SSU and TCP connection negotiation (not
compatible with previous builds)
* Enable the backwards incompatible tunnel crypto change as documented in
tunnel-alt.html (have each hop encrypt the received IV before using it,
then encrypt it again before sending it on)
* Disable the I2CP encryption, leaving in place the end to end garlic
encryption (another backwards incompatible change)
* Adjust the protocol versions on the TCP and SSU transports so that they
won't talk to older routers.
* Fix up the config stats handling again
* Fix a rare off-by-one in the SSU fragmentation
* Reduce some unnecessary netDb resending by inluding the peers queried
successfully in the store redundancy count.
* increased the maximum number of fragments allowed in a message from 31 to 127,
reducing the maximum fragment size to 8KB and moving around some bits in the fragment
info. This is not backwards compatible.
* removed the old (hokey) congestion control description, replacing it with the TCP-esque
algorithm implemented
note: the code for the ACK bitfields and fragment info changes have not yet been
implemented, so the old version of this document describes whats going on in the live net.
the new bitfields / fragment info should be deployed in the next day or so (hopefully :)
* include a new signedOnTime so that we can prepare the packet at a different moment from
when we encrypt & send it (also allowing us to reuse that signature on resends for the same
establishment)
* added more inbound tests
* made the tunnel preprocessing header more clear and included better fragmentation support
(still left: tests for outbound tunnel processing, structures and jobs to integrate with the router,
remove that full SHA256 from each and every I2NPMessage or put a smaller one at the
transport layer, and all the rest of the tunnel pooling/building stuff)
tunnel ID they listen on and make sure the previous peer doesn't change over time. The
worst that a hostile peer could do is create a multiplicative work factor - they send N
messages, causing N*#hops in the loop of bandwidth usage. This is identical to the hostile
peer simply building a pair of tunnels and sending N messages through them.
also added some discussion about the tradeoffs and variations wrt fixed size tunnel messages.
This prevents the first peer after the gateway from looking at the encrypted data received
and seeing "hey, none of the checksum blocks match the payload, they must be the gateway".
