Opened 20 months ago
Last modified 7 months ago
#24680 new enhancement
If the fallback list has 200-300 entries, make the tor binary smaller by reducing the size of the fallback list strings
| Reported by: | teor | Owned by: | |
|---|---|---|---|
| Priority: | Medium | Milestone: | |
| Component: | Core Tor/Fallback Scripts | Version: | |
| Severity: | Normal | Keywords: | ideas binary-size |
| Cc: | Actual Points: | ||
| Parent ID: | Points: | 1 | |
| Reviewer: | Sponsor: |
Description
We could make the following strings shorter:
- orport
- id
- ipv6
- weight
This has a minor readability impact. This also makes it harder to unify this code with the directory authority code.
We could encode the id as base64, but I think we'd need atlas support for that first. And it interferes with readability/searchability for operators.
We could teach Tor that the default fallback weight is N (N=9,10?), and then remove the weights.
Child Tickets
Change History (8)
comment:1 Changed 20 months ago by
comment:3 Changed 20 months ago by
[But is this actually helpful? fallback_dirs.inc is less than 1% of the final binary size, if I'm counting right]
comment:4 Changed 20 months ago by
I don't think it's worth optimising at the moment.
It might be worth optimising if we follow the original proposal, and choose 20% of guards as fallbacks (~500 entries). Or if the network grows dramatically, and we add more fallbacks.
comment:7 Changed 7 months ago by
| Sponsor: | Sponsor8-can |
|---|
comment:8 Changed 7 months ago by
| Summary: | Make tor binary smaller by reducing the size of the fallback list strings → If the fallback list has 200-300 entries, make the tor binary smaller by reducing the size of the fallback list strings |
|---|
Let's keep this ticket, in case we decide to increase the fallback list to 300 entries.
Replying to teor:
This is done in #24679.