- Dec 22, 2005
-
-
- Dec 21, 2005
-
-
- Dec 20, 2005
-
-
- Dec 19, 2005
-
-
* I2PSnark logging, disconnect old inactive peers rather than new ones, memory usage reduction, better OOM handling, and a shared connection acceptor. * Cleaned up the Syndie blog page and the resulting filters (viewing a blog from the blog page shows threads started by the selected author, not those that they merely participate in)
-
- Dec 18, 2005
-
-
* Added a standalone runner for the I2PSnark web ui (build with the command "ant i2psnark", unzip i2psnark-standalone.zip somewhere, run with "java -jar launch-i2psnark.jar", and go to http://localhost:8002/). * Further I2PSnark error handling
-
- Dec 17, 2005
-
-
- Dec 16, 2005
-
-
- Dec 15, 2005
-
-
* Added multitorrent support to I2PSnark, accessible currently by running "i2psnark.jar --config i2psnark.config" (which may or may not exist). It then joins the swarm for any torrents in ./i2psnark/*.torrent, saving their data in that directory as well. Removing the .torrent file stops participation, and it is currently set to seed indefinitely. Completion is logged to the logger and standard output, with further UI interaction left to the (work in progress) web UI.
-
- Dec 14, 2005
-
-
- Dec 13, 2005
-
-
* Don't test tunnels expiring within 90 seconds * Defer Test Tunnel jobs if job lag too large * Use JobQueue.getMaxLag() rather than the jobQueue.jobLag stat to measure job lag for tunnel build backoff, allowing for more agile handling (since the stat is only updated once a minute) * Use tunnel length override if all tunnels are expiring within one minute. -
-
- Dec 09, 2005
-
-
* Create different strategies for exploratory tunnels (which are difficult to create) and client tunnels (which are much easier) * Gradually increase number of parallel build attempts as tunnel expiry nears. * Temporarily shorten attempted build tunnel length if builds using configured tunnel length are unsuccessful * React more aggressively to tunnel failure than routine tunnel replacement * Make tunnel creation times randomized - there is existing code to randomize the tunnels but it isn't effective due to the tunnel creation strategy. Currently, most tunnels get built all at once, at about 2 1/2 to 3 minutes before expiration. The patch fixes this by fixing the randomization, and by changing the overlap time (with old tunnels) to a range of 2 to 4 minutes. * Reduce number of excess tunnels. Lots of excess tunnels get created due to overlapping calls. Just about anything generated a call which could build many tunnels all at once, even if tunnel building was already in process. * Miscellaneous router console enhancements
-
- Dec 08, 2005
-
-
- Dec 07, 2005
-
-
- Dec 05, 2005
-
-
- Dec 04, 2005
-
-
- Dec 03, 2005
-
-
-
-
* Package up a standalone Syndie install into a "syndie-standalone.zip", buildable with "ant syndie". It extracts into ./syndie/, launches with "java -jar launchsyndie.jar" (or javaw, on windows, to avoid a dos box), running a single user Syndie instance (by default). It also creates a default subscription to syndiemedia without any anonymity (using no proxy). Upgrades can be done by just replacing the syndie.war with the one from I2P.
-
- Dec 01, 2005
-
-
- Nov 30, 2005
-
-
* Don't let the TCP transport alone shitlist a peer, since other transports may be working. Also display whether TCP connections are inbound or outbound on the peers page. * Fixed some substantial bugs in the SSU introducers where we wouldn't talk to anyone who didn't expose an IP (even if they had introducers), among other goofy things. * When dealing with SSU introducers, send them all a packet at 3s/6s/9s, rather than sending one a packet at 3s, then another a packet at 6s, and a third a packet at 9s. * Fixed Syndie attachments (oops)
-
- Nov 29, 2005
-
-
-
* Further Syndie UI cleanup * Bundled our patched MultiPartRequest code from jetty (APL2 licensed), since it hasn't been applied to the jetty CVS yet [1]. Its packaged into syndie.jar and renamed to net.i2p.syndie.web.MultiPartRequest, but will be removed as soon as its integrated into Jetty. This patch allows posting content in various character sets. [1] http://article.gmane.org/gmane.comp.java.jetty.general/6031 * Upgraded new installs to the latest stable jetty (5.1.6), though this isn't pushed as part of the update yet, as there aren't any critical bugs. -
* Added back in the OSX jbigi, which was accidentally removed a few revs back (thanks for the bug report stoerte!) New installs will get the full jbigi, or you can pull the jbigi.jar from CVS by going to http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/installer/lib/jbigi/jbigi.jar and clicking on the first "download" link, saving that jbigi.jar to lib/jbigi.jar in your I2P installation directory. After restarting your router, it should load up fine.
-
- Nov 28, 2005
-
-
* Inlined the Syndie CSS to reduce the number of HTTP requests (and because firefox [and others?] delay rendering until they fetch the css). * Make sure we fire the shutdown tasks when regenerating a new identity (thanks picsou!) * Cleaned up some of the things I b0rked in the 'dynamic keys' mode * Don't drop SSU sessions if they're still transmitting data successfully, even if there are transmission failures * Adjusted the time summarization to display hours after 119m, not 90m * Further EepGet cleanup (grr)
-
- Nov 26, 2005
-
-
-
* Update the sorting in Syndie to consider children 'newer' than parents, even if they have the same message ID (duh) * Cleaned up some nav links in Syndie (good idea gloin, spaetz!) * Added a bunch of tooltips to Syndie's fields (thanks polecat!) * Force support for nonvalidating XML in Jetty (so we can handle GCJ/etc better) -
-
* Added support for 'dynamic keys' mode, where the router creates a new router identity whenever it detects a substantial change in its public address (read: SSU IP or port). This only offers minimal additional protection against trivial attackers, but should provide functional improvement for people who have periodic IP changes, since their new router address would not be shitlisted while their old one would be. * Added further infrastructure for restricted route operation, but its use is not recommended. -
-
- Nov 25, 2005
-
-
- Nov 24, 2005
-
-
