Opened 3 years ago

Closed 16 months ago

#18564 closed defect (fixed)

Improve our client HS descriptor fetch logic

Reported by: dgoulet Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, tor-client
Cc: Actual Points:
Parent ID: Points: 3
Reviewer: Sponsor: SponsorR-can

Description

(This was discovered because of #15937)

Considering a client that does 6 connections attempt to a .onion very fast, currently we'll do 6 fetches of the descriptor thus on all 6 HSDirs. Furthermore, once the descriptor arrives on the client, we do NOT terminate the 5 other requests...

I think we should do the following:

  • Have parallel descriptor fetches because multiple requests improve our chances of getting the descriptor faster (maybe). I'm proposing that we use one third of the HSDirs set that is 2 HSDirs (one per replica) over our 6 in total. (I'm open also to half of the hsdirs, just that one third makes it easy to query replicas in a symmetric way.)

If they all fail, query an other sset or if only one fails, relaunch one immediately (so we avoid one HSDir stalling everything) so we always have one third of our set being queried.

  • Once the descriptor arrives, terminate the other pending HSDir fetch connections.
  • When a .onion request arrives on the SocksPort, check if we have pending descriptor fetch(es) and if yes, we should wait! don't launch more! If it's lower than our threshold (in this example 2/6), launch new fetches until we reach that limit and wait.

This should also cover the HSFETCH control command with a .onion address which doesn't require to have a SERVER= set.

Child Tickets

Change History (7)

comment:1 Changed 2 years ago by nickm

Points: medium

comment:2 Changed 2 years ago by arma

I think we should do the same fetch behavior regardless of how many client requests are pending.

The simple answer then is to do one fetch and wait for it to succeed or fail.

If we want to get fancy, we could launch a few in parallel, and close down the others once one succeeds. (Benefit: you get your answer more reliably and probably a bit more quickly. Drawback: you load down the network more, and also you expose your interest in the onion service to more relays.)

But it seems crazy to me to have more outstanding fetches as we have more pending client requests.

Last edited 2 years ago by arma (previous) (diff)

comment:3 Changed 2 years ago by isabela

Milestone: Tor: 0.2.9.x-finalTor: 0.2.???

tickets market to be removed from milestone 029

comment:4 Changed 22 months ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:5 Changed 21 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:6 Changed 16 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:7 Changed 16 months ago by dgoulet

Keywords: tor-client added
Points: medium3
Resolution: fixed
Status: newclosed

Not doing that.

Note: See TracTickets for help on using tickets.