[tor-bugs] #25964 [Core Tor/Tor]: Remove hs_index_t fetch, and use one of the stores instead

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Apr 30 14:22:48 UTC 2018


#25964: Remove hs_index_t fetch, and use one of the stores instead
--------------------------------------+----------------------------------
 Reporter:  teor                      |          Owner:  (none)
     Type:  enhancement               |         Status:  new
 Priority:  Medium                    |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor              |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  technical-debt, refactor  |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+----------------------------------

Comment (by dgoulet):

 Datapoint:

 The function that does all the hsdir index magic assignment is:
 `node_set_hsdir_index()`.

 > analyse the state machine of fetch, store_first, and store_second to
 make sure that fetch is always equal to store_first or store_second

 We have to be very careful here. This hsdir index logic has been a source
 of complexity that created many headache during the prop224 development.
 We have a very very very important unit tests that makes sure client and
 service will always be in sync with the hashring and thus the index they
 compute. See in `test_hs_common.c`: `reachability_scenarios` so at least
 if that passes, we should be maybe be OK.

 > write a function that produces fetch from a hsdir_index_t, and use it
 instead of fetch

 To clarify this a bit. We do *not* compute HSDir index on the fly but
 rather when the node_t is added to the nodelist. And we should keep it
 that way because else, everytime you want to upload or download a
 descriptor, you would need to compute all the indexes for all the nodes to
 get the full hashring.

 v2 used the relay identity but in v3, we do a computation that changes
 every time there is a new SRV and entering a new time period.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25964#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list