- 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
-
- Apr 13, 2006
-
-
- Apr 12, 2006
-
- Apr 11, 2006
-
-
* Throttling improvements on SSU - throttle all transmissions to a peer when we are retransmitting, not just retransmissions. Also, if we're already retransmitting to a peer, probabalistically tail drop new messages targetting that peer, based on the estimated wait time before transmission. * Fixed the rounding error in the inbound tunnel drop probability.
-
- Apr 10, 2006
-
- Apr 09, 2006
-
- Apr 08, 2006
-
-
* Process inbound tunnel requests more efficiently * Proactively drop inbound tunnel requests if the queue before we'd process it in is too long (dynamically adjusted by cpu load) * Adjust the tunnel rejection throttle to reject requeusts when we have to proactively drop too many requests. * Display the number of pending inbound tunnel join requests on the router console (as the "handle backlog") * Include a few more stats in the default set of graphs
-
- Apr 07, 2006
-
- Apr 06, 2006
-
- Apr 05, 2006
-
-
-
* Cut down on the time that we allow a tunnel creation request to sit by without response, and reject tunnel creation requests that are lagged locally. Also switch to a bounded FIFO instead of a LIFO * Threading tweaks for the message handling (thanks bar!) * Don't add addresses to syndie with blank names (thanks Complication!) * Further ban clearance
-
* weekly news.xml update
-
- Apr 04, 2006
-
-
* Fix during the ssu handshake to avoid an unnecessary failure on packet retransmission (thanks ripple!) * Fix during the SSU handshake to use the negotiated session key asap, rather than using the intro key for more than we should (thanks ripple!) * Fixes to the message reply registry (thanks Complication!) * More comprehensive syndie banning (for repeated pushes) * Publish the router's ballpark bandwidth limit (w/in a power of 2), for testing purposes * Put a floor back on the capacity threshold, so too many failing peers won't cause us to pick very bad peers (unless we have very few good ones) * Bugfix to cut down on peers using introducers unneessarily (thanks Complication!) * Reduced the default streaming lib message size to fit into a single tunnel message, rather than require 5 tunnel messages to be transferred without loss before recomposition. This reduces throughput, but should increase reliability, at least for the time being. * Misc small bugfixes in the router (thanks all!) * More tweaking for Syndie's CSS (thanks Doubtful Salmon!)
-
- Apr 03, 2006
-
- Apr 01, 2006
-
- Mar 30, 2006
-
-
* Substantially reduced the lock contention in the message registry (a major hotspot that can choke most threads). Also reworked the locking so we don't need per-message timer events * No need to have additional per-peer message clearing, as they are either unregistered individually or expired. * Include some of the more transient tunnel throttling
-
- Mar 29, 2006
-
-
* weekly news.xml update
-
- Mar 27, 2006
-
-
* announce 0.6.1.3
-
- Mar 26, 2006
-
-