]> git.ipfire.org Git - thirdparty/tor.git/commit
Improve fairness when activating streams in circuit_resume_edge_reading_helper
authorMashael AlSabah <malsabah@cs.uwaterloo.ca>
Mon, 29 Nov 2010 20:34:21 +0000 (15:34 -0500)
committerNick Mathewson <nickm@torproject.org>
Mon, 29 Nov 2010 20:34:21 +0000 (15:34 -0500)
commit12fa6e23cb4a45c51ae2ca9bddaabfc5da4ebb6e
tree12873f11e4c1dd9bbe72f13a327f9c1b34627f64
parenta5174b092e17169d4d640ae73a7b4ed26b3d4c10
Improve fairness when activating streams in circuit_resume_edge_reading_helper

 The reason the "streams problem" occurs is due to the complicated
interaction between Tor's congestion control and libevent. At some point
during the experiment, the circuit window is exhausted, which blocks all
edge streams. When a circuit level sendme is received at Exit, it
resumes edge reading by looping over linked list of edge streams, and
calling connection_start_reading() to inform libevent to resume reading.
When the streams are activated again, Tor gets the chance to service the
first three streams activated before the circuit window is exhausted
again, which causes all streams to be blocked again. As an experiment,
we reversed the order in which the streams are activated, and indeed the
first three streams, rather than the last three, got service, while the
others starved.

 Our solution is to change the order in which streams are activated. We
choose a random edge connection from the linked list, and then we
activate streams starting from that chosen stream. When we reach the end
of the list, then we continue from the head of the list until our chosen
stream (treating the linked list as a circular linked list). It would
probably be better to actually remember which streams have received
service recently, but this way is simple and effective.
src/or/relay.c