Re: [tor-dev] Proposal: Controller events to better understand connection/circuit usage

On 2/22/13 8:50 PM, Rob Jansen wrote:
Your understanding of n_circ_id and p_circ_id matches mine, but are you sure there's a UID for circuits other than origin circuits? I think you mean origin_circuit_t->global_identifier. But there's no such field for or_circuit_t or circuit_t. Or do you mean something else? Anyway, your description made me realize that my previous attempt to link CELL_STATS events was flawed for (at least) two reasons: 1. I assumed that a circuit ID (n_circ_id or p_circ_id) is unique for a given pair of nodes, but it's really only unique for a given connection between two nodes. 2. I also assumed that a circuit uses two different connections for inbound and outbound queues, but it's actually the same connection that is known under different connection IDs by the involved nodes. Maybe this gets clearer when looking again at the example: [fileclient-60.1.0.0]:[tokenconn-59.1.0.0]:34760 00:23:16 [fileclient-60.1.0.0] >>> circ=34760 conn=12 create_fast=1;relay_early=2 create_fast=1;relay_early=2 00:23:16 [tokenconn-59.1.0.0] <<< circ=34760 conn=31 relay=1;created_fast=1 relay=1;created_fast=1 Circuit ID 34760 is what fileclient picked as n_circ_id for this circuit and what tokenconn stored as p_circ_id. There's a single OR connection carrying this circuit which fileclient identifies as 12 and tokenconn as 31. The part where this gets tricky is when we need to find out (reliably) that connection IDs 12 and 31 refer to the same connection. fileclient never tells tokenconn that it locally refers to this connection as ID 12, and vice versa. However, there can be more than one connection between the two nodes, and it's perfectly valid for those connections to each have a circuit with ID 34760 on them. I modified my Java program to parse ORCONN events to match corresponding connection IDs based on state transitions from NEW or LAUNCHED to CONNECTED. This works in 99% of cases and only fails for OR connections that were launched before the controller registered for ORCONN events. But we probably don't care about that early bootstrapping phase anyway. Here's the same circuit from my original example, this time with explanations (IDs might differ, because this example comes from another Shadow run): [fileclient-60.1.0.0]:12:34761 This queue is for circuit 34761 which runs over connection 12 at fileclient. It's an outbound queue, though that isn't explicitly stated here. The ID 34761 is what fileclient picked as n_circ_id. 00:23:16 [fileclient-60.1.0.0] >>> circ=34761 conn=12 create_fast=1;relay_early=2 create_fast=1;relay_early=2 There were three cells in outbound direction reported in this CELL_STATS event. Leaving out other CELL_STATS events here. [tokenconn-59.1.0.0]:31:34761 This queue is also for circuit 34761, but running over connection 31 at tokenconn. It's an inbound queue, so 34761 is a p_circ_id, chosen by fileclient. 00:23:16 [tokenconn-59.1.0.0] <<< circ=34761 conn=31 relay=1;created_fast=1 relay=1;created_fast=1 Two cells in inbound direction. [tokenconn-59.1.0.0]:16:26405 Queue for circuit 26405 on connection 16 at relay tokenconn. [tokenglobal-57.1.0.0]:15:26405 See above. [tokenglobal-57.1.0.0]:16:53557 See above. [exit2-62.1.0.0]:15:53557 See above. tl;dr: I _think_ it's possible to reconstruct circuits from ORCONN and CELL_STATS events as they are currently specified in proposal 218. Best, Karsten
participants (1)
-
Karsten Loesing