Re: [tor-bugs] #14847 [Tor]: Controller: add a command to fetch HS descriptor from HSdir(s)

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs