<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> Hi, </div><div>the last mail got rejected by tor-dev, to keep track of this thread, sending again, sorry for disturbing,</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, Apr 15, 2016 at 5:37 AM, George Kadianakis <span dir="ltr"><<a href="mailto:desnacked@riseup.net" target="_blank">desnacked@riseup.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>Fan Jiang <<a href="mailto:fanjiang@thoughtworks.com" target="_blank">fanjiang@thoughtworks.com</a>> writes:<br>
<br>
> [ text/plain ]<br>
</span><span>> Thanks for the insights.<br>
><br>
><br>
>> >> It seems like the latest version of prop259 was posted a few weeks ago:<br>
>> >><br>
>> <a href="https://lists.torproject.org/pipermail/tor-dev/2016-March/010625.html" rel="noreferrer" target="_blank">https://lists.torproject.org/pipermail/tor-dev/2016-March/010625.html</a><br>
>> >><br>
</span>>> > <snip><br>
<span>>> ><br>
>> >> A few things:<br>
>> >><br>
>> >> a) Are there still proposal design decisions that need to be taken and<br>
>> we<br>
>> >> are<br>
>> >>    unclear on? I admit I'm a bit lost in the latest [tor-dev] thread, so<br>
>> >> maybe<br>
>> >>    I can be of help somehow here?<br>
>> >><br>
>> >> There are still some issues, like for_directory may leads to maintain<br>
>> two<br>
>> > sets of<br>
>> > sampled_set independently, which is not yet defined clearly in proposal.<br>
>> ><br>
>><br>
>> Hm, how come this is happening?<br>
>><br>
>> I would think that for_directory would now be just another filter (like the<br>
>> ipv6 one etc.) that can be applied on top of the sampled list.<br>
>><br>
> The problem here is for_directory is a parameter of function call, that<br>
> means we can't do filter<br>
> before the call happens. Now the filter action only happens at START stage.<br>
> Maybe do a check before we return the selected guard (if not valid, then<br>
> continue picking new one)<br>
> can be a solution.<br>
><br>
<br>
</span>Hello,<br>
<br>
hm, that's an interesting problem...<br>
<br>
So we learn whether a circuit is for_directory when<br>
choose_random_entry_prop259() is called, but at that point the prop259<br>
algorithm has already STARTed and its filtering parameters have been<br>
determined?<br>
<br>
So if some part of tor calls choose_random_entry_prop259() quickly twice, first<br>
with for_directory set, and the second time with for_directory unset, the guard<br>
algorithm will proceed in both cases with for_directory being set? Because the<br>
context has been set in the first call to choose_random_entry_prop259()?<br>
<br>
This seems like a problem to me, and I'm not sure how to solve it well...<br>
<br>
One way could be to use the 'cpath_build_state_t *state' in<br>
choose_random_entry_prop259() to be able to understand whether each call is<br>
about a different circuit or not. Then you could start a separate algorithm<br>
invocation (so new START) for each new circuit you see.<br>
<br>
But then I'm not sure how to do this without each separate algorithm call<br>
wrecking up the sampled_guards and used_guards lists... In the dev meeting in<br>
Valencia, we discussed with Ola and Reinaldo about using locking and blocking<br>
for this, but I'm not sure how much that would impact the performance...<br>
<br>
Do you guys have any plans here?<br>
<br></blockquote></div></div><div>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), </div><div>and they can be checked with directory flag before return.</div><div>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,</div><div>Or if you have any ideas please let me know.</div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
---<br>
<br>
<br>
<br>
BTW, I also noticed that you have various global structures in prop259.c, like<br>
entry_guard_selection and used_guards and sampled_guards. I see you've been<br>
working hard on un-globalizing the entry_guards list, but I'm not sure if there<br>
is value to that if all those other structures are global. Do you have plans<br>
for making those structures local to each specific algorithm instance?<br>
<br></blockquote></span><div>I've been working on moving these other structures into a guard_selection_t,</div><div>and hope it can help to make this algo instanceable.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Cheers!<br></blockquote></div></div></div></blockquote></div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div><br></div></div></div></div></div></div></div></div>
</div></div>