[tor-dev] Meeting about the new guard algorithm proposal (prop259)

[Reinaldo de Souza Jr]

Thank you.

Another thing I'm interested in is how the proposed algorithm structure
fits into current tor code. The proposed algorithm is:

    OPEN_CIRCUIT:
      context = ALGO_CHOOSE_ENTRY_GUARD_START(...)
      while True:
        entryGuard = ALGO_CHOOSE_ENTRY_GUARD_NEXT(context)
        circuit = composeCircuitAndConnect(entryGuard)

        if not SHOULD_CONTINUE(isSuccessful(circuit)):
          ALGO_CHOOSE_ENTRY_GUARD_END(context, entryGuard)
          return circuit

I'd like to have ideas of current tor functions with similar purposes.
This is the correlation I was able to find by reading the source code:

a) OPEN_CIRCUIT()
Seems to be equivalent to circuit_establish_circuit()

b) while True:
Seems to be equivalent to onion_populate_cpath(). It even has a
"timeout" after 32 tries!

c) ALGO_CHOOSE_ENTRY_GUARD_NEXT(context)
Seems to be equivalent to choose_good_entry_server() as used in
onion_extend_cpath().

d) composeCircuitAndConnect(entryGuard)
This is the most uncertain to me. It seems to be circuit_handle_first_hop().

The issue is: we rely on `unreachable_since` being updated in case we
fail to connect to the guard before the next call to (c). In current tor
code, this is done by entry_guard_register_connect_status() but I got
lost tracking when it happens.

circuit_mark_for_close_() seems to be called when
circuit_handle_first_hop() fails but it's unclear to me if
entry_guard_register_connect_status() will ever be called as part of
circuit_mark_for_close_() - and if there is any guarantee it will be
called before the next invocation of onion_extend_cpath().

e) SHOULD_CONTINUE(isSuccessful(circuit))
This is also tricky. If onion_extend_cpath() is our loop, this is
supposed to break it in some case.

It is very similar to how entry_guard_register_connect_status() is used
in channel_do_open_actions(). But similarly to
entry_guard_register_connect_status(), I'm also unsure if
channel_do_open_actions() is called as part of onion_extend_cpath().

f) ALGO_CHOOSE_ENTRY_GUARD_END()
It could be entry_guard_register_connect_status().

Sorry for such a dense email. I'm trying to make an informed decision
before following my gut seeing how it breaks.

If there is any technique or call graph tool you find useful to get such
information, it would be much appreciated.

-- 
*Reinaldo de Souza Jr* | Software Developer
*Thought*Works Brasil

GPG: E0FD 0487 5CAC 4200 EF25 098A 9FA3 789F 0615 5999

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160318/1e9a9ee4/attachment-0001.sig>