[tor-dev] Channel incoming queue

[Andrea Shepard]

On Thu, May 02, 2013 at 10:58:54AM -0400, MF Nowlan wrote:
> Hi all,
> 
> I am working on integrating uTCP and uTLS (
> http://arxiv.org/abs/1103.0463) into Tor to see if we can lower the
> latency due to head of line blocking across circuits. This is
> Tracker Item #7679 (
> https://trac.torproject.org/projects/tor/ticket/7679). I want to
> first test the Tor code's ability to process cells from different
> circuits out of order with respect to how TCP delivered them. To
> test this, I made some changes to the file named src/or/channel.c.
> 
> 1. I forced queueing of cells into the channel's incoming_queue with:
> channel_queue_cell(...) {
> ...
> need_to_queue = 1; // Force all cells into the queue, so they do NOT
> go directly to the handler.
> ...
> 
> 2. Now, look for case when two cells from different circuits are
> present in the incoming_queue and process the second cell before the
> first cell.
> channel_process_cells(...) {
> ...
>   while (NULL != (q = TOR_SIMPLEQ_FIRST(&chan->incoming_queue))) {
>     // Remove q from the incoming_queue.
>     // if the queue is still not empty, get the next one,
>     // if the circuit ids do not match, Swap the cells.
>   }
> ...
> }
> 
> My problem is that number 2. above never occurs. I have not observed
> a case where the incoming_queue ever has two cells from different
> circuits. In fact, I don't think I've ever had a time when the
> incoming_queue has more than 1 cell in it.  I am hammering a small
> tor test network with 30+ curl requests at once. I have two proxies,
> each of them uses the same entry node, and the same exit node, and
> there is only one other node in the network, so the circuit that is
> set up should be the same for every single request.  Am I missing
> something? Will this function (channel_process_cells) ever process
> more than one cell at a time? I've checked the logs to verify that
> different circuits are actually set up for the different requests
> (rather than the Proxies just reusing the existing circuit and
> giving each new request a new stream id).

[I wrote the channel code, so I'll explain it]

Under normal operation with the current channeltls.c implementation, those
queues should rarely, if ever have more than one cell.  The queue exists
because the channel abstraction includes possibilities like going temporarily
into CHANNEL_STATE_MAINT and not processing new traffic, in which case those
queues will accumulate temporarily unprocessable cells.  I believe some of
the opening and closing cases might cause them to fill.  None of these normally
occur with channeltls.c, which is currently the only channel implementation
layer, and at least the CHANNEL_STATE_MAINT one never occurs.

Short version: you're seeing normal behavior, don't worry about it.

-- 
Andrea Shepard
<andrea at torproject.org>
PGP fingerprint: 3611 95A4 0740 ED1B 7EA5  DF7E 4191 13D9 D0CF BDA5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 847 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130509/ad031857/attachment.pgp>