proto: Encapsulate stream mux into a new abstraction
Per discussion: We want to encapsulate the current code in the circuit reactor that read from all the stream MPSC queues into a single more or less opaque type that hides the implementation details. Once we've done this, we can implement fancier behavior.
Once we have done that, we can make other improvements, including:
-
better fairness among streams. DONE. We implement round robin scheduling across streams. -
less searching over lists of streams. DONE. We've added StreamPollSet
so that we don't iterate over streams that have nothing to send, and pushed flow-control down into afutures::Stream
adapter so that we also don't iterate over streams that can't currently send due to flow-control. -
being able to take amounts of data other than maximum DATA message size -
letting streams queue small amounts of data without necessarily flushing a full DATA message -
abstracting flow control for XON/XOFF vs SENDME. Partly done. We have an initial version of this abstraction ( tor_proto::stream::flow_control
), but haven't yet implemented the XON/XOFF variant. - ... ?
The first step here is to define what the API truly looks like. It's probably something like a per-stream "sender", combined with a reactor-held "receiver".
(We should figure out if there is one of these per hop, or if it can multiplex across multiple hops. Each possibility has its pros and cons.)
cc @jnewsome
Edited by Jim Newsome