[tor-bugs] #16389 [Tor]: Redesign the HS client descriptor cache

[Tor Bug Tracker & Wiki]

#16389: Redesign the HS client descriptor cache
-------------------------+--------------------------------
     Reporter:  dgoulet  |      Owner:
         Type:  defect   |     Status:  reopened
     Priority:  major    |  Milestone:  Tor: 0.2.8.x-final
    Component:  Tor      |    Version:
   Resolution:           |   Keywords:  SponsorR, tor-hs
Actual Points:           |  Parent ID:  #16381
       Points:           |
-------------------------+--------------------------------
Changes (by nickm):

 * keywords:  SponsorR, tor-hs, TorCoreTeam201508 => SponsorR, tor-hs
 * milestone:  Tor: 0.2.7.x-final => Tor: 0.2.8.x-final


Old description:

> Bug #16381 vs #14219 demonstarted an important issue with the current
> design of the HS client descriptor cache.
>
> In a nutshell, we can't rely on the timestamp to order descriptors
> because the timestamp is rounded down to the nearest hour thus any change
> in that time period will never be seen by the client (#16381).
> Furthermore, we can't rely on comparing the descriptor content because we
> have two replicas with the same content but have different descriptor ID
> (#14219).
>
> One solution proposed by arma (and +1 by special) is to redesign the
> logic to be cleaner, and keep an intro point failure cache. It seems like
> every time we encounter this "we keep state about the previous hs desc by
> keeping a copy of it, and then seeing if the new one is different, get
> it?" logic, somebody finds it confusing. Maybe now is a good time for it
> to die? :)

New description:

 '''We merged a patch here, but see arma's comment below.'''

 Bug #16381 vs #14219 demonstarted an important issue with the current
 design of the HS client descriptor cache.

 In a nutshell, we can't rely on the timestamp to order descriptors because
 the timestamp is rounded down to the nearest hour thus any change in that
 time period will never be seen by the client (#16381). Furthermore, we
 can't rely on comparing the descriptor content because we have two
 replicas with the same content but have different descriptor ID (#14219).

 One solution proposed by arma (and +1 by special) is to redesign the logic
 to be cleaner, and keep an intro point failure cache. It seems like every
 time we encounter this "we keep state about the previous hs desc by
 keeping a copy of it, and then seeing if the new one is different, get
 it?" logic, somebody finds it confusing. Maybe now is a good time for it
 to die? :)

--

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