- Dec 05, 2014
-
-
zzz authored
-
zzz authored
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)
-
- Dec 02, 2014
- Nov 28, 2014
-
-
kytv authored
-
- Nov 27, 2014
- Nov 24, 2014
- Nov 22, 2014
-
-
zzz authored
It was starting both the v3 and v1 acceptors.
-
- Nov 21, 2014
- Nov 13, 2014
-
-
zzz authored
- 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.
-
- Nov 12, 2014
- Nov 11, 2014
-
-
zzz authored
-
- Nov 09, 2014
- Nov 08, 2014
- Nov 06, 2014
- Nov 05, 2014
- Nov 04, 2014
-
-
zzz authored
-
- Nov 02, 2014
-
-
zzz authored
-
zzz authored
-
zzz authored
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
-
- Nov 01, 2014
-
-
zzz authored
Fix history.txt UTF-8 breakage Javadoc fixes after review
-
- Oct 31, 2014
-
-
str4d authored
-
- Oct 30, 2014
- Oct 29, 2014
- Oct 28, 2014
-
-
zzz authored
-