Reinaldo de Souza Jr rjunior@thoughtworks.com writes:
That would be great!
OK. Let's say Wednesday 15:00 UTC then!
I have a couple of questions that may help me better prepare for this meeting:
- In the proposal we assume the arrival of a new consensus as a
discrete event. Does this assumption match current tor implementation, or is it more like "having at least X relay descriptors available"? What is the entrypoint for taking actions after we receive a new consensus?
Indeed, in the current tor implementation it's a discrete event.
See entry_guards_compute_status() called by directory_info_has_arrived().
Keep in mind we refer to "receiving a new consensus" meaning "the list of guards has changed", they might be different things. We are interested in reacting to changes to the "list of guards".
- Once we have a guard_t, how can we know if it "is present in the
latest consensus"?
We found the property `bad_since` but it seems to have a different semantics: when the guard was considered "nonfunctional, unlisted, excluded, or otherwise nonusable" (according to `ENTRY_GUARD_REMOVE_AFTER` description).
We also found `entry_guard_set_status` and how it consider a guard to be unlisted: a failure to find a node with the same identity as the guard using node_get_by_id().
At this point, my understanding is whatever is "in the consensus" can be found by node_get_by_id() and `bad_since` can be used as an additional data for decision making. Is this correct?
Took a quick look and I think you are right.
node_get_by_id() uses the global nodelist for lookups. The global nodelist gets updated everytime tor receives a new consensus. So if node_get_by_id() can't find a node, it means it was not listed in the previous consensus.
Specifically in entry_guards_compute_status() we have:
SMARTLIST_FOREACH_BEGIN(entry_guards, entry_guard_t *, entry) { const node_t *r = node_get_by_id(entry->identity); const char *reason = NULL; if (entry_guard_set_status(entry, r, now, options, &reason)) changed = 1; ... } SMARTLIST_FOREACH_END(entry);
- Current tor implementation seems to prefer handling lists of node_t
rather than entry_guard_t, is there a reason for this?
I think tor uses entry_guard_t simply as a store of guard-related information about a node. However, to actually do networking with a node (e.g. connect to it) you need to go from entry_guard_t to node_t, because it's node_t that has networking capabilities.
Cheers!
The proposal implementation currently manipulate lists of entry_guard_t but when we need to call functions in existing tor code (node_sl_choose_by_bandwidth) we need to convert from guard do node, using node_get_by_id().
As a consequence, if I'm correct about 2, this will automatically filter out unlisted guards.
On 3/18/16 04:19, George Kadianakis wrote:
Hello there,
seems like the prop259 algorithm has kind of stabilized and you guys have jumped into implementation. That's great!
A small problem in this process is that I'm probably the only person in Tor who understands the new algorithm right now. We could fix this by doing a small proposal IRC meeting where you guys could summarize the current state of the algorithm, as well as provide some simulation results. I think that folks like Nick, Mike and isis could provide valuable feedback at this point.
Would you guys be interested in something like this? I'm fine with doing it next week at some point. Maybe Wednesday or Thursday? Maybe at 15:00 UTC? Let me know if that's convenient for you.
Cheers!