I2P Address: [http://git.idk.i2p]

Skip to content
Snippets Groups Projects
  1. May 07, 2004
    • jrandom's avatar
      logging, javadoc · 766c1224
      jrandom authored and zzz's avatar zzz committed
      766c1224
    • jrandom's avatar
      made private things that don't need to be public · a82b951a
      jrandom authored and zzz's avatar zzz committed
      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)
      a82b951a
  2. May 04, 2004
  3. May 03, 2004
    • jrandom's avatar
      refactored packet handling into type specific methods · 60584228
      jrandom authored and zzz's avatar zzz committed
      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.
      60584228
  4. Apr 20, 2004
  5. Apr 19, 2004
  6. Apr 16, 2004
    • human's avatar
      First step for the "connection refused" concept: incoming connections · 031338d8
      human authored and zzz's avatar zzz committed
      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()).
      031338d8
  7. Apr 10, 2004
  8. Apr 08, 2004
Loading