[tor-dev] Channel incoming queue

[MF Nowlan]

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).

Thanks for the help!

Fitz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130502/9a215116/attachment.html>