* 2004-11-26 0.4.2 released
2004-11-26 jrandom
* Enable the new streaming lib as the default. That means, for any
substantial definition, it is NOT BACKWARDS COMPATIBLE.
* Revised the installer to include start menu and desktop shortcuts for
windows platforms, including pretty icons (thanks DrWoo!)
* Allow clients specified in clients.config to have an explicit startup
delay.
* Update the default install to launch a browser pointing at the console
whenever I2P starts up, rather than only the first time it starts up
(configurable on /configservice.jsp, or in clients.config)
* Bugfix to the clock skew checking code to monitor the delta between
offsets, not the offset itself (duh)
* Router console html update
* New (and uuuuugly) code to verify that the wrapper.config contains
the necessary classpath entries on update. If it has to update the
wrapper.config, it will stop the JVM and service completely, since the
java service wrapper doesn't reread the wrapper.config on JVM restart -
requiring the user to manually restart the service after an update.
* Increase the TCP connection timeout to 30s (which is obscenely long)
------------------------------------------------
* Remove spurious flush calls from I2PTunnel, and work with the
I2PSocket's output stream directly (as the various implementations
do their own buffering).
* Another pass at a long standing JobQueue bug - dramatically simplify
the job management synchronization since we dont need to deal with
high contention (unlike last year when we had dozens of queue runners
going at once).
* Logging
* Fix for a long standing synchronization bug in the JobQueue (and added
some kooky flags to make sure it stays dead)
* Update the ministreaming lib to force mode=guaranteed if the default
lib is used, and mode=best_effort for all other libs.
* Fixed up the configuration overrides for the streaming socket lib
integration so that it properly honors env settings.
* More memory usage streamlining (last major revamp for now, i promise)
2004-10-30 jrandom
* Cache the temporary objects used in the AES encryption/decryption
process so that AES doesn't require any memory allocation to process
data.
* Dramatically reduce memory usage within various crypto implementations
by avoiding unnecessary (though simplifying) buffers.
* If we specify some tags to be sent in an I2CP message explicitly, use
only those, not those plus a new set (otherwise we aren't sure on ACK
which set was delivered)
* Allow configuration for the partial send timeout (how long before
resending a message down a different tunnel in a lease). This can be
updated with the "router.clientPartialSendTimeout" router config prop.
* Logging
* properly close the source file in StreamSinkSend
* always adjust the rtt on ack, not just for packets with 1 send
* handle dup SYN gracefully
* revamp the default connection options
* logging
* Allow explicit inclusion of session tags in the SDK, enabling the
resending of tags bundled with messages that would not otherwise
be ACKed.
* Don't force mode=guaranteed for end to end delivery - if mode=bestEffort
no DeliveryStatusMessage will be bundled (and as such, client apps using
it will need to do their own session tag ack/nack).
* Handle client errors when notifying them of message availability.
* New StreamSinkSend which sends a file to a destination and disconnects.
* Update the I2PSocketManagerFactory to build the specific
I2PSocketManager instance based on the "i2p.streaming.manager" property,
containing the class name of the I2PSocketManager implementation to instantiate.
or even whether to have the blocking action timeout and close the socket after
a certain delay
* refactored the I2PSocketOptions to be more actively used
* added a pair of ministreaming lib demo apps:
- StreamSinkServer listens to a destination and dumps any data it receives on a socket to a per-socket file
- StreamSinkClient sends a destination a specified number of random bytes, then disconnects
(this is what caused the runtime errors on sun jvms but not on kaffe)
((aka i slacked and didn't test sufficiently. off with my head))
this now builds and runs fine in sun 1.3-1.5 jvms, as well as kaffe
new async interface for error notification (e.g. you can get notified of an error prior to it throwing the IOException).
This async is useful since the IOException can be delayed for up to a minute while waiting for the close packet to be delivered.
The alternative is to fire off a new thread to do the closing, and we may want to go there later, but i'm not sure.
* 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)
remove semantic inconsistency wrt getRemoteId(false) - it shouldn't ever timeout, since it always returns immediately
javadoc (though i wish i understood the close/close2/sendClose more clearly so i could javadoc that process)
removed nested synchronization (which had been causing undetected deadlocks)
made sync blocks smaller, though this may have opened holes related to
resent ACK/SYN/CLOSE packets that are delivered in a race. I'm not as
fluent in the ministreaming lib code as i should be (yet), but duck's thread
dumps were showing hundreds of threads waiting on a lock that'll never get
released (since the only way to release it would be to receive another
packet, and no more packets can be received until the lock is released, etc)
also, I2PSession is threadsafe - i can see no reason to synchronize on it
(and it was being synchronized on only part of the time?)
also, refactored the charset encoding stuff and minor log tweaking
i've been testing this for the last hour or so, on eepsites and squid (large
and small files), as well as irc, and there haven't been any glitches. but
it needs more testing before it can be released, obviously.
