- 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
-
-
- Mar 25, 2006
-
-
* Added a simple purge and ban of syndie authors, shown as the "Purge and ban" button on the addressbook for authors that are already on the ignore list. All of their entries and metadata are deleted from the archive, and the are transparently filtered from any remote syndication (so no user on the syndie instance will pull any new posts from them) * More strict tunnel join throtting when congested
-
