On Fri, Apr 15, 2016 at 5:37 AM, George Kadianakis <desnacked@riseup.net> wrote:

Fan Jiang <fanjiang@thoughtworks.com> writes:

> [ text/plain ]
> Thanks for the insights.
>
>
>> >> It seems like the latest version of prop259 was posted a few weeks ago:
>> >>
>> https://lists.torproject.org/pipermail/tor-dev/2016-March/010625.html
>> >>
>> > <snip>
>> >
>> >> A few things:
>> >>
>> >> a) Are there still proposal design decisions that need to be taken and
>> we
>> >> are
>> >>    unclear on? I admit I'm a bit lost in the latest [tor-dev] thread, so
>> >> maybe
>> >>    I can be of help somehow here?
>> >>
>> >> There are still some issues, like for_directory may leads to maintain
>> two
>> > sets of
>> > sampled_set independently, which is not yet defined clearly in proposal.
>> >
>>
>> Hm, how come this is happening?
>>
>> I would think that for_directory would now be just another filter (like the
>> ipv6 one etc.) that can be applied on top of the sampled list.
>>
> The problem here is for_directory is a parameter of function call, that
> means we can't do filter
> before the call happens. Now the filter action only happens at START stage.
> Maybe do a check before we return the selected guard (if not valid, then
> continue picking new one)
> can be a solution.
>

Hello,

hm, that's an interesting problem...

So we learn whether a circuit is for_directory when
choose_random_entry_prop259() is called, but at that point the prop259
algorithm has already STARTed and its filtering parameters have been
determined?

So if some part of tor calls choose_random_entry_prop259() quickly twice, first
with for_directory set, and the second time with for_directory unset, the guard
algorithm will proceed in both cases with for_directory being set? Because the
context has been set in the first call to choose_random_entry_prop259()?

This seems like a problem to me, and I'm not sure how to solve it well...

One way could be to use the 'cpath_build_state_t *state' in
choose_random_entry_prop259() to be able to understand whether each call is
about a different circuit or not. Then you could start a separate algorithm
invocation (so new START) for each new circuit you see.

But then I'm not sure how to do this without each separate algorithm call
wrecking up the sampled_guards and used_guards lists... In the dev meeting in
Valencia, we discussed with Ola and Reinaldo about using locking and blocking
for this, but I'm not sure how much that would impact the performance...

Do you guys have any plans here?

We can have two pending_guard one for directory, one for any usage(which will be picked by the NEXT algo, so they can be same node), 

and they can be checked with directory flag before return.

Locking may not work because this algo should at least return sth before it continues to another one, saying Dir and non-Dir are now in main loop,

Or if you have any ideas please let me know.

---



BTW, I also noticed that you have various global structures in prop259.c, like
entry_guard_selection and used_guards and sampled_guards. I see you've been
working hard on un-globalizing the entry_guards list, but I'm not sure if there
is value to that if all those other structures are global. Do you have plans
for making those structures local to each specific algorithm instance?

I've been working on moving these other structures into a guard_selection_t,

and hope it can help to make this algo instanceable.

 

Cheers!