[tor-bugs] #14847 [Tor]: Controller: add a command to fetch HS descriptor from HSdir(s)
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sat Feb 14 09:25:47 UTC 2015
#14847: Controller: add a command to fetch HS descriptor from HSdir(s)
-----------------------------+----------------------------------------
Reporter: dgoulet | Owner: dgoulet
Type: enhancement | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.7.x-final
Component: Tor | Version:
Resolution: | Keywords: SponsorR tor-hs controller
Actual Points: | Parent ID: #3521
Points: |
-----------------------------+----------------------------------------
Comment (by arma):
Replying to [comment:9 dgoulet]:
> Ok, with all the comments above, here is a much simpler version.
>
> See branch {{{ticket14847_03}}}.
What's the reasoning for the cache=yes or cache=no part? That is, why not
just let rend_cache_store_v2_desc_as_client(() look at the hsdesc you get
back and decide whether to keep it based on whatever rules it uses now ("I
don't have a newer one, etc")?
I think to do the async thing here we'll want to extend the HSDESC event
to just tell you the descriptor right then. Otherwise there's a three step
process ("initiate the launch", "notice the event", "getinfo the
response"), and if you initiate a bunch of launches, and then get a bunch
of events, you'll only be able to getinfo one of them, and you might not
even know which one it was, etc.
(Whether you extend the HSDESC event always, or add a separate
HSDESC_AND_DUMP event, or what, is a matter of taste that I will leave to
you and Nick if you like this approach.)
Now that I think about it, there may also be some adventure here with all
of the implicit "oh a failure just happened, that means I should launch
this other action" logic in hsdesc fetches. Maybe this is a good time to
clean up some of that logic, or maybe it will turn out to be easier than
we think to work with it. Or I guess option three is that this will just
be no fun. :)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14847#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list