- Aug 08, 2004
-
- Aug 05, 2004
-
-
instead of the standard 'httpclient 4444' or 'httpclient 4444 squid.i2p', you can now specify a comma delimited list of outproxies: 'httpclient 4444 squid.i2p,www1.squid.i2p,www2.squid.i2p' and each individual http request goes through a randomly selected proxy there are a few general issues with this, such as a lack of affinity (web applications that require a session to always come from a single IP address will break) but it should work most of the time.
-
- Aug 03, 2004
-
- Jul 15, 2004
-
- Jul 12, 2004
-
- Jul 11, 2004
-
- Jul 10, 2004
-
-
added support for new 'clientoptions' command which alters the properties passed when creating subsequent I2CP connections e.g.: -e "clientoptions tunnels.depthInbound=0" -e "httpclient 6666" this updates so many files because they all need a reference to an I2PTunnel object on construction so they query tunnel.getClientOptions() instead of System.getProperties
-
- Jul 02, 2004
-
- Jun 28, 2004
-
- Jun 27, 2004
-
- May 24, 2004
-
- May 19, 2004
-
- 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 05, 2004
-
- May 04, 2004
-
- May 03, 2004
-
- Apr 30, 2004
-
- Apr 24, 2004
-
-
a rooted app context. The core itself has its own I2PAppContext (see its javadoc for, uh, docs), and the router extends that to expose the router's singletons. The main point of this is to make it so that we can run multiple routers in the same JVM, even to allow different apps in the same JVM to switch singleton implementations (e.g. run some routers with one set of profile calculators, and other routers with a different one). There is still some work to be done regarding the actual boot up of multiple routers in a JVM, as well as their configuration, though the plan is to have the RouterContext override the I2PAppContext's getProperty/getPropertyNames methods to read from a config file (seperate ones per context) instead of using the System.getProperty that the base I2PAppContext uses. Once the multi-router is working, i'll shim in a VMCommSystem that doesn't depend upon sockets or threads to read/write (and that uses configurable message send delays / disconnects / etc, perhaps using data from the routerContext.getProperty to drive it). I could hold off until the sim is all working, but there's a truckload of changes in here and I hate dealing with conflicts ;) Everything works - I've been running 'er for a while and kicked the tires a bit, but if you see something amiss, please let me know.
- Apr 23, 2004
-
- Apr 21, 2004
-
- Apr 20, 2004
-
- Apr 19, 2004
-
- Apr 14, 2004
-
- Apr 10, 2004
-
- Apr 09, 2004
-
- Apr 08, 2004
-