Opened 3 years ago

Closed 8 months ago

#20132 closed enhancement (duplicate)

Let large client deployments use a local directory cache

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, tor2web, single-onion, tor-client, efficiency, needs-design
Cc: Actual Points:
Parent ID: #13932 Points: 1
Reviewer: Sponsor: Sponsor4-can

Description

One of the things that concerns me about large tor client farms is that they download a ~1.5MB consensus per client per hour.

This is a particular concern with large deployments of bridges, hidden services (particularly with OnionBalance and/or single onion services), and Tor2web.

One way to work around this issue is to set up a number of local Tor directory caches (unadvertised relays) on the machines hosting the Tor client instances. Then the clients can be told to use these directory caches to retrieve their directory documents.

Ideally, each client should be configured with a few caches in the same data center, just in case one goes down.

It would really help to have a client option for this in Tor, but there is a tradeoff - compromise that relay, and you own all the clients.

For Tor2web and Single Onion Services, this almost works already using EntryNodes, but we disable EntryGuards in order to turn off path bias detection. Also, Single Onion Services use 3-hop paths for HSDir posts, and we want Tor2web to use 3-hop paths for HSDir fetches to avoid denial of service (#20104).

Child Tickets

Change History (8)

comment:1 in reply to:  description ; Changed 3 years ago by arma

Replying to teor:

One of the things that concerns me about large tor client farms is that they download a ~1.5MB consensus per client per hour.

It should in theory be compressed, so smaller than that. But yes, it is a lot over time, per client.

It would really help to have a client option for this in Tor, but there is a tradeoff - compromise that relay, and you own all the clients.

In theory, this is what DirPort was for long ago. If you set up one Tor client with a DirPort, and set httpproxy on your other clients, then they'll ask their dir questions to the one central client. I guess this is a bit trickier nowadays with the begindir style questions, but that's a simple matter of turning off ... wait, it appears that we ripped out TunnelDirConns. Well, we used to have this functionality, back in the day. :)

comment:2 in reply to:  1 Changed 3 years ago by teor

Replying to arma:

Replying to teor:

One of the things that concerns me about large tor client farms is that they download a ~1.5MB consensus per client per hour.

It should in theory be compressed, so smaller than that. But yes, it is a lot over time, per client.

It would really help to have a client option for this in Tor, but there is a tradeoff - compromise that relay, and you own all the clients.

In theory, this is what DirPort was for long ago. If you set up one Tor client with a DirPort, and set httpproxy on your other clients, then they'll ask their dir questions to the one central client. I guess this is a bit trickier nowadays with the begindir style questions, but that's a simple matter of turning off ... wait, it appears that we ripped out TunnelDirConns. Well, we used to have this functionality, back in the day. :)

FallbackDir still has this effect - set up one relay (doesn't have to be public), add it as the FallbackDir for all your clients, your clients go to it first, then go to the authorities.

Of course, if your FallbackDir dies, all your clients hammer the authorities.

comment:3 Changed 3 years ago by teor

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

Milestone renamed

comment:4 Changed 3 years 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:5 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:6 Changed 2 years ago by teor

Keywords: single-onion added; rsos removed

Now there's only one kind of single onion service, change rsos to single-onion

comment:7 Changed 2 years ago by nickm

Keywords: tor-client efficiency needs-design added
Sponsor: Sponsor4-can

comment:8 Changed 8 months ago by teor

Parent ID: #13932
Resolution: duplicate
Status: newclosed

Duplicate of #13932.

Note: See TracTickets for help on using tickets.