#19327: controller: expose fine-grained circuit detail. -------------------------------------------------+------------------------- Reporter: nickm | Owner: (none) Type: enhancement | Status: | needs_review Priority: Medium | Milestone: Tor: | unspecified Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: tor-control isolation test-support | Actual Points: intro | Parent ID: #17284 | Points: 2 Reviewer: nickm | Sponsor: | SponsorS-can -------------------------------------------------+-------------------------
Comment (by nickm): Replying to [comment:10 aveuiller]: > I looked at the `origin_circuit_st` struct and wanted to be sure that I understood the meaning and > importance of the different attributes in the call result. That's a good place to start! I'd suggest also looking at the members of circuit_t, since every origin_circuit_t contains a circuit_t object. If you want to do an initial breakdown of those, I can look at that list too. > The following attributes seem to be interesting to add with the proposed keyword: > > - associated_isolated_stream_global_id (ASSOCIATED_STREAM_ID) > - isolation_values_set (ISOLATION_SET) > - isolation_flags_mixed (ISOLATION_MIXED) > - isolation_any_streams_attached (ANY_STREAM_ATTACHED) > - client_proto_type (CLIENT_PROTO_TYPE) > - client_proto_socksver (CLIENT_PROTO_SOCKSVER) > - dest_port (DEST_PORT) > - client_addr (CLIENT_ADDR) > - dest_address (DEST_ADDRESS) > - session_group (SESSION_GROUP) > - nym_epoch (NYM_EPOCH) These are all isolation-related, so let's hold off on them till we have a design for #19859 > - n_read_circ_bw (BYTE_READ_BW) > - n_written_circ_bw (BYTE_WRITTEN_BW) > - n_delivered_read_circ_bw (CELL_READ_BW) > - n_delivered_written_circ_bw (CELL_WRITTEN_BW) > - n_overhead_read_circ_bw (CELL_OVER_READ_BW) > - n_overhead_written_circ_bw (CELL_OVER_WRITTEN_BW) These fields are already exposed via the CIRC_BW controller event; they aren't really meaningful on their own. > - remaining_relay_early_cells (REMAINING_RELAY_EARLY_CELLS) > - circuit_idle_timeout (IDLE_TIMEOUT) > - unusable_for_new_conns (UNUSABLE_FOR_NEW_CONNS) > - padding_negotiation_failed (PADDING_NEGOTIATION_FAILED) > - path_state (PATH_STATE) This are potentially useful. > - relaxed_timeout (HAS_RELAXED_TIMEOUT) > - is_ancient (IS_ANCIENT) > - has_opened (HAS_OPENED) > - prepend_policy (PREPEND_POLICY) > - hs_circ_has_timed_out (HS_HAS_TIMED_OUT) These will be a little tricky to document: they all have somewhat complicated logic. They were all originally used to implement code of the form "Remember when X has happened, so we can do Y", and that's what their documentation says. But it's possible that the conditions when we want to do Y, or the ways in which we respond to X, will change over time. So we should document which condition we actually want each of the controller flags to represent: does it represent "this is a field where X has happened" or "this is a field where we Y"? We should carefully document what each one actually means in practice. > This makes the following attributes remaining non-printed: > > - p_streams > - half_streams > - guard_state These might be worth potentially exposing some information about in the future, but it doesn't have to be now. > - relay_early_cells_sent This is worth exposing, and easy to expose. > - global_origin_circuit_list_idx This is an implementation detail and should not be exposed. > - pathbias_probe_id > - pathbias_probe_nonce > - hs_service_side_rend_circ_has_been_relaunched I don't think there's any reason to expose these, but I could be wrong. > - relay_early_commands I think we should remove this field; it doesn't seem to be doing anything useful any more, and nobody has encountered bug #878 for a long time. > - next_stream_id We could expose this, but I don't see any reason to do so. > - intro_key We shouldn't expose this. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19327#comment:14> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs