Ticket25762 034 04 #56
Conversation
No behavior change, just to make it easier to find callbacks and for the sake of our human brain to parse the list properly. Signed-off-by: David Goulet <dgoulet@torproject.org>
In tor, we have a series of possible "roles" that the tor daemon can be enabled for. They are: Client, Bridge, Relay, Authority (directory or bridge) and Onion service. They can be combined sometimes. For instance, a Directory Authority is also a Relay. This adds a "roles" field to a periodic event item object which is used to know for which roles the event is for. The next step is to enable the event only if the roles apply. No behavior change at this commit. Pars of #25762 Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: David Goulet <dgoulet@torproject.org>
In case we transitionned to a new role in Tor, we need to launch and/or destroy some periodic events. Signed-off-by: David Goulet <dgoulet@torproject.org>
Two helper functions to enable an event and disable an event which wraps the launch and destroy of an event but takes care of the enabled flag. They are also idempotent that is can be called multiple time on the same event without effect if the event was already enabled or disabled. Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: David Goulet <dgoulet@torproject.org>
Signed-off-by: David Goulet <dgoulet@torproject.org>
Pull Request Test Coverage Report for Build 552
|
I've checked this over, and I confirm nothing is dropped.
| /* Routers (bridge and relay) only. */ | ||
| CALLBACK(check_descriptor, PERIODIC_EVENT_ROLE_ROUTER), | ||
| CALLBACK(check_ed_keys, PERIODIC_EVENT_ROLE_ROUTER), | ||
| CALLBACK(check_for_reachability_bw, PERIODIC_EVENT_ROLE_ROUTER), |
Do bridges evaluate their reachability and bw? If so, this is right.
I believe so as server_mode() is used in that function thus bridges should do it.
Seems fine here from IRC discussion.
| CALLBACK(check_onion_keys_expiry_time, PERIODIC_EVENT_ROLE_ROUTER), | ||
| CALLBACK(clean_consdiffmgr, PERIODIC_EVENT_ROLE_ROUTER), | ||
| CALLBACK(expire_old_ciruits_serverside, PERIODIC_EVENT_ROLE_ROUTER), | ||
| CALLBACK(retry_dns, PERIODIC_EVENT_ROLE_ROUTER), |
Bridges shouldn't do this, should they?
retry_dns() uses server_mode() so maybe we should use public_server_mode() there if you think it is no good?
We'll open a new ticket here since retry_dns() only applies to Exit node thus the role should be Relay but also the function should use public_server_mode() or actually straight options->ExitRelay.
I opened #25899 for this.
| CALLBACK(check_ed_keys, PERIODIC_EVENT_ROLE_ROUTER), | ||
| CALLBACK(check_for_reachability_bw, PERIODIC_EVENT_ROLE_ROUTER), | ||
| CALLBACK(check_onion_keys_expiry_time, PERIODIC_EVENT_ROLE_ROUTER), | ||
| CALLBACK(clean_consdiffmgr, PERIODIC_EVENT_ROLE_ROUTER), |
I think this needs a separate "DirServer" role, unless it is going to be "Everyone". We have a bug recently where we assumed that all DirServers were relays of some kind, but that doesn't seem to be true.. See trac:23693
Again as above, server_mode() is used meaning bridge go in that path. And because all relays are DirServer, it seems OK to assign the Router role where a bridge also will serve consensus to their clients thus need to clean the cache?
Per IRC discussion, we need a DirServer role since DirCache 0 will make this callback pointless for a relay.
I opened #25900 for this
|
This has been merged. |
No description provided.
The text was updated successfully, but these errors were encountered: