forked from torps/torps
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathTODO
More file actions
14 lines (14 loc) · 2.15 KB
/
Copy pathTODO
File metadata and controls
14 lines (14 loc) · 2.15 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# TODO
# - support IPv6 addresses
# - We do not consider removing stable/fast requirements if a suitable relay can't be found at some point. Tor does this. Rather, we just error.
# - Instead of immediately using a new consensus, set a random time to
# switch to the new one, following the process in dir-spec.txt (Sec. 5.1).
# - Do something intelligent with empty node sets rather than just raise error. Relatedly, do checks for sufficient nodes to create paths, and raise informative errors if not.
# - circuits only recorded as fast/stable/internal if they were chosen to
# satisfy that, but they may just by chance. should we check?
# - Tor actually seems to build a circuit to cover a port by randomly selecting from exits that cover *some* unhandled port (see choose_good_exit_server_general() in circuitbuild.c). Possibly change procedure for covering ports to act like this.
# - We should expire descriptors older than router_max_age on a per-minute basis. I'm not sure exactly how relays in the consensus but without descriptors are treated, especially in terms of putting guards down. As an approximation, we expire descriptors while building consensuses, and thus do so at most an hour off from when a running relay would. Given that router_max_age is 48 hours, that not large relative error for how long a relay may be used. Also, I don't think that in the Tor metrics data a relay ever appears in the consensus but does not have a recent descriptor.
# - When processing descriptors, missing consensuses shouldn't result in a missing network state file. Hibernations may still occur during that time, and so it may be better to have a dummy file that just repeats the most recent consensus.
# - consider moving guard expiration out of period_update into timed_update - is guard expiration actually done on an hourly basis or more often? (doesn't matter that much - guard expiration is on order of months)
# - Change the way actual adversarial bandwidth is turned into a consensus bandwidth. Total consensus weight fluctuates a surprising amount, and so we should normalize the adversarial consensus weight on a per-consensus basis.
# - move to using logging module for all debug output