- Jun 09, 2006
-
-
- Jun 05, 2006
-
-
-
* Stop sending a blank line before USER in susimail. Seemed to break in rare cases, thanks for reporting, Brachtus!
-
- Jun 04, 2006
-
-
- May 31, 2006
-
-
* Only send netDb searches to the floodfill peers for the time being * Add some proof of concept filters for tunnel participation. By default, it will skip peers with an advertised bandwith of less than 32KBps or an advertised uptime of less than 2 hours. If this is sufficient, a safer implementation of these filters will be implemented. -
* weekly news.xml update
-
- May 19, 2006
-
-
* news.xml update
-
- May 18, 2006
-
-
-
* Fix some oversights in my previous changes: adjust some loglevels, make a few statements less wasteful, make one comparison less confusing and more likely to log unexpected values -
-
- May 16, 2006
-
-
- May 15, 2006
-
-
- May 14, 2006
-
-
* Update the build number too
-
* Separate growth factors for tunnel count and tunnel test time * Reduce growth factors, so probabalistic throttle would activate * Square probAccept values to decelerate stronger when far from average * Create a bandwidth stat with approximately 15-second half life * Make allowTunnel() check the 1-second bandwidth for overload before doing allowance calculations using 15-second bandwidth * Tweak the overload detector in BuildExecutor to be more sensitive for rising edges, add ability to initiate tunnel drops * Add a function to seek and drop the highest-rate participating tunnel, keeping a fixed+random grace period between such drops. It doesn't seem very effective, so disabled by default ("router.dropTunnelsOnOverload=true" to enable)
-
- May 12, 2006
-
-
- May 10, 2006
-
-
* weekly news.xml update
-
- May 09, 2006
-
-
- May 08, 2006
-
-
* Fix problem whereby repeated calls to allowed() would make the 1-tunnel exception permit more than one concurrent build
-
- May 06, 2006
-
-
- May 04, 2006
-
-
- May 03, 2006
-
-
* Allow a single build attempt to proceed despite 1-minute overload only if the 1-second rate shows enough spare bandwidth (e.g. overload has already eased) -
* Correct a misnamed property in SummaryHelper.java to avoid confusion * Make the maximum allowance of our own concurrent tunnel builds slightly adaptive: one concurrent build per 6 KB/s within the fixed range 2..10 * While overloaded, try to avoid completely choking our own build attempts, instead prefer limiting them to 1 -
* Fixed URL in previous update, sorry
-
* Weekly news.xml update
-
- May 01, 2006
-
-
* Adjust the tunnel build timeouts to cut down on expirations, and increased the SSU connection establishment retransmission rate to something less glacial. * For the first 5 minutes of uptime, be less aggressive with tunnel exploration, opting for more reliable peers to start with. -
-
-
- Apr 28, 2006
-
-
- Apr 26, 2006
-
-
* weekly news.xml update
-
- Apr 24, 2006
-
-
* Update news.xml to reflect 0.6.1.17
-
- Apr 23, 2006
-
-
- Apr 22, 2006
-
-
- Apr 19, 2006
-
-
* Adjust how we pick high capacity peers to allow the inclusion of fast peers (the previous filter assumed an old usage pattern) * New set of stats to help track per-packet-type bandwidth usage better * Cut out the proactive tail drop from the SSU transport, for now * Reduce the frequency of tunnel build attempts while we're saturated * Don't drop tunnel requests as easily - prefer to explicitly reject them
-
- Apr 15, 2006
-
-
* Update news.xml to reflect 0.6.1.16
-
-
-
- Apr 14, 2006
-
-
