jrandom authored 20 years ago and zzz committed 20 years ago

    * Minor ministreaming lib refactoring to simplify integration of the full
      streaming lib.
    * Minor bugfixes to data structure serialization.

jrandom authored 20 years ago and zzz committed 20 years ago

arrggggh, 1.4-ism that kaffe supports (but sun-1.3 users havent complained about). (thanks frontier)

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

only block adding more *outbound* data, not handling data received from I2P.  The data has already been received by the router and delivered to the streaming lib (and is sitting in RAM anyway...)
logging

jrandom authored 20 years ago and zzz committed 20 years ago

have a write() timeout after 60s instead of blocking forever by default (also used when injecting data into an input stream)

jrandom authored 20 years ago and zzz committed 20 years ago

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

jrandom authored 20 years ago and zzz committed 20 years ago

logging, including replacing the scary monster with its true self (we had data queued up, but were unable to get an ACK on our last write)

jrandom authored 20 years ago and zzz committed 20 years ago

the actual fix for the local eepsite problem (if getRemoteID was called *after* the remoteID was set, it would wait for 60s then fail.  now we check for that)
synchronization cleanup (never get two locks)
logging

jrandom authored 20 years ago and zzz committed 20 years ago

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.

mihi authored 20 years ago and zzz committed 20 years ago

(you may remove both comments when you understood it)

[mihi]

jrandom authored 20 years ago and zzz committed 20 years ago

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)

jrandom authored 20 years ago and zzz committed 20 years ago

add unique IDs to the various threads for logging / tracing purposes

jrandom authored 20 years ago and zzz committed 20 years ago

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.

human authored 20 years ago and zzz committed 20 years ago

could solve duck's problems with dangling threads...
(human)

human authored 20 years ago and zzz committed 20 years ago

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()).

jrandom authored 20 years ago and zzz committed 20 years ago

name all threads, and (nearly) always use I2PThread (in case we add some pooling/throttling/monitoring or whatnot later)