Big savings is on client side (two less threads per connection)
- Move client pool from static inI2PTunnelClientBase to TCG.
- Use client pool for some server threads
- Run some things inline that were formerly threads
- Client-side I2PTunnelRunner thread used to do nothing but start 2 more
threads; now it runs one inline (like we do for server-side HTTP)
- Javadocs and cleanups
Was originally intended to reduce load for high-traffic servers
but most of the savings for now is on the client side.
Ref: http://zzz.i2p/topics/1741
Todo: Figure out how to run the HTTP client-side gunzipper inline too
Todo: More server-side improvements
---
Client side:
before:
4-5 threads, 1-2 pooled
I2PTunnel Client Runner (BlockingRunner from client pool)
starts I2PTunnelRunner or I2PTunnelHTTPClientRunner and exits
starts StreamForwarder toI2P and waits
starts StreamForwarder fromI2P and waits
starts HTTPResponseOutputStream (HTTP gunzip only) (from client pool)
now:
2-3 threads, 1-2 pooled
I2PTunnel Client Runner (BlockingRunner from client pool)
runs I2PTunnelRunner or I2PTunnelHTTPClientRunner inline
starts StreamForwarder toI2P and waits
runs StreamForwarder fromI2P inline
starts HTTPResponseOutputStream (HTTP gunzip only) (from client pool)
---
Server side:
before:
1-4 threads, 0-1 pooled
Server Handler Pool (Handler from server pool) execpt for standard server, blockingHandle() inline in acceptor
starts I2PTunnelRunner or CompressedRequestor and exits
starts StreamForwarder toI2P and waits (inline for HTTP)
starts StreamForwarder fromI2P and waits (except not for HTTP GET)
now:
1-4 threads, 0-2 pooled
Server Handler Pool (Handler from server pool) execpt for standard server, blockingHandle() inline in acceptor
starts I2PTunnelRunner or CompressedRequestor and exits (using client pool)
starts StreamForwarder toI2P and waits (inline for HTTP)
starts StreamForwarder fromI2P and waits (except not for HTTP GET)
- Fix bug that left server acceptor thread running after close
- Add destroy() methods to release all resources when closing a tunnel for good,
particularly the streaming timer threads
- Use COWAL to prevent concurrency problems
- Javadocs
Streaming:
- Don't return null from accept() any more; actually throw
ConnectException as the javadocs have always specified
- Throw ConnectException from accept() if interrupted; previously caught and ignored
- Throw exceptions from ConnectionHandler.accept(), not higher up
- Close ServerSocket when ConnectionManager is shut down
- Synchronize setActive(), clear queue when starting to accept,
better handling of calls that don't change state
- Javadocs
ConfigClientsHelper: Call isPluginRunning() less often
PluginStarter: Simplify detection of active threads
Above changes mostly in support of zzzot plugin implementing ClientApp
and being able to shut down completely so there are no threads
in its thread group, so /configclients will all show status as stopped.
Previously, the I2PTunnelServer acceptor thread and
one or more streaming timer threads would remain.
ECDSA default for all new server tunnels
ECDSA default for streamr client tunnels
Fix display of server destination on edit page when not running (privkey file path wasn't absolute)
Fix display of persistent client key b32 on edit page when not running
Fix display of server sig type on edit page when we have a privkey file
Add KeysAndCert.getSigType()
Javadocs
- Better handling of unsupported encryption in destinations
- Implement handling of unsupported encryption in router identities
- Banlist forever all RIs with unsupported encryption
- New negative cache of all dests with unsupported encryption
- New methods for destination lookup that will succeed even if
the LS is expired or encryption is unsupported
- Use new dest lookup so client will get the right error code
later, rather than failing with no LS when we really got it
but just couldn't verify it.
- Cleanups and javadocs
OCMOSJ: Detect unsupported encryption on dest and return the correct failure code
through I2CP to streaming to i2ptunnel
Streaming: Re-enable message status override, but treat LS lookup failure
as a soft failure for now.
HTTP Client: Add error page for unsupported encryption
- Verify crypto key pair in LS
- Verfiy same dest as before in LS
Router: Don't try to use an unavailable sig type for the router,
even if it's the default
RouterInfo: Work around unsupported raw signatures for
RI Ed25519 sig type
- Add local SSL support for std. and IRC client tunnels (ticket #1107)
Keystore goes in ~/.i2p/keystore; pubkey cert goes in ~/.i2p/certificates/i2ptunnel
- Escape messages to index page
- Show message for uncaught exception
