- Oct 24, 2004
-
-
- Oct 07, 2004
-
-
- Oct 01, 2004
-
-
- Sep 26, 2004
-
-
- Aug 25, 2004
-
-
- Aug 15, 2004
-
-
- Aug 07, 2004
-
-
- Aug 06, 2004
-
-
- Aug 01, 2004
-
-
-
-
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
-
- Jul 20, 2004
-
-
- Jul 16, 2004
-
-
- Jul 01, 2004
-
-
- Jun 30, 2004
-
-
- Jun 28, 2004
-
-
- Jun 27, 2004
-
-
- May 19, 2004
-
-
-
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.
-
- May 17, 2004
-
-
- May 16, 2004
-
-
* 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)
-
- May 07, 2004
-
-
- May 04, 2004
-
-
- May 03, 2004
-
-
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.
-
- Apr 21, 2004
-
-
- Apr 20, 2004
-
-
- Apr 19, 2004
-
-
- Apr 16, 2004
-
-
won't be accepted until the server app actually requires an I2PServerSocket from the I2PSocketManager. It allows both to add a little bit of functionality, and to fix a nasty bug: it was possible to hang an app that connects through the I2PSocketManager but actually doesn't accept() connections (if 2 connection requests were sent to the app, the I2PSocketManager got stuck waiting forever on I2PServerSocketImpl.getNewSocket()).
-
- Apr 14, 2004
-
-
<http://dev.i2p.net/pipermail/i2p/2004-April/000214.html>; * slightly revised locking; * made accept() throw a ConnectException when the I2PServerSocket is closed. (human)
-
