mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-11 05:33:47 +01:00
107 lines
3.1 KiB
Plaintext
107 lines
3.1 KiB
Plaintext
|
Filename: xxx-bootstrap-phases.txt
|
||
|
|
Title: Keep controllers informed as Tor bootstraps
|
||
|
|
Version: $Revision$
|
||
|
|
Last-Modified: $Date$
|
||
|
|
Author: Roger Dingledine
|
||
|
|
Created: 07-Jun-2008
|
||
|
|
Status: Open
|
||
|
|
|
||
|
|
1. Overview.
|
||
|
|
|
||
|
|
Tor has many steps to bootstrapping directory information and
|
||
|
|
initial circuits, but from the controller's perspective we just have
|
||
|
|
a coarse-grained "CIRCUIT_ESTABLISHED" status event. Tor users with
|
||
|
|
slow connections or with connectivity problems can wait a long time
|
||
|
|
staring at the yellow onion, wondering if it will ever change color.
|
||
|
|
|
||
|
|
This proposal describes a new client status event so Tor can give
|
||
|
|
more details to the controller. Section 2 describes the changes to the
|
||
|
|
controller protocol; Section 3 describes Tor's internal bootstrapping
|
||
|
|
phases assuming everything goes correctly; and Section 4 describes
|
||
|
|
how and when Tor chooses to issue bootstrap warnings.
|
||
|
|
|
||
|
|
2. Controller event syntax.
|
||
|
|
|
||
|
|
The generic status event is:
|
||
|
|
|
||
|
|
"650" SP StatusType SP StatusSeverity SP StatusAction
|
||
|
|
[SP StatusArguments] CRLF
|
||
|
|
|
||
|
|
So in this case we send
|
||
|
|
650 STATUS_CLIENT NOTICE/WARN BOOTSTRAP \
|
||
|
|
PROGRESS=num TAG=string SUMMARY=string
|
||
|
|
|
||
|
|
"Progress" gives a number between 0 and 100 for how far through
|
||
|
|
the bootstrapping process we are. "Summary" is a string that can be
|
||
|
|
displayed to the user to describe the *next* task that Tor will tackle,
|
||
|
|
i.e., the task it is working on after sending the status event. "Tag"
|
||
|
|
is an optional string that controllers can use to recognize bootstrap
|
||
|
|
phases from Section 3, if they want to do something smarter than just
|
||
|
|
blindly displaying the summary string.
|
||
|
|
|
||
|
|
The severity describes whether this is a normal bootstrap phase
|
||
|
|
(severity notice) or an indication of a bootstrapping problem
|
||
|
|
(severity warn).
|
||
|
|
|
||
|
|
3. The bootstrap phases.
|
||
|
|
|
||
|
|
Phase 0: tag=STARTING
|
||
|
|
|
||
|
|
Phase 5: tag=CONN_DIR
|
||
|
|
|
||
|
|
Phase 10: tag=HANDSHAKE_DIR
|
||
|
|
|
||
|
|
Phase 15: tag=ONEHOP_CREATE
|
||
|
|
|
||
|
|
Phase 20: tag=REQUESTING_STATUS
|
||
|
|
|
||
|
|
Phase 25: tag=LOADING_STATUS
|
||
|
|
|
||
|
|
Phase 40: tag=LOADING_KEYS
|
||
|
|
|
||
|
|
Phase 45: tag=REQUESTING_DESCRIPTORS
|
||
|
|
|
||
|
|
Phase 50: tag=LOADING_DESCRIPTORS
|
||
|
|
|
||
|
|
Phase 80: tag=CONN_OR
|
||
|
|
|
||
|
|
Phase 85: tag=HANDSHAKE_OR
|
||
|
|
|
||
|
|
Phase 90: tag=CIRCUIT_CREATE
|
||
|
|
|
||
|
|
Phase 100: tag=DONE
|
||
|
|
|
||
|
|
|
||
|
|
5: fetching authority key certs
|
||
|
|
LOADING_KEYS
|
||
|
|
(authority_certs_fetch_missing)
|
||
|
|
10: Connecting to directory mirror
|
||
|
|
CONN_DIR
|
||
|
|
(circuit_handle_first_hop)
|
||
|
|
15: Finishing handshake with directory mirror
|
||
|
|
HANDSHAKE_DIR
|
||
|
|
(connection_or_finished_connecting)
|
||
|
|
20: Establishing one-hop circuit for dir info
|
||
|
|
ONEHOP_CREATE
|
||
|
|
(circuit_send_next_onion_skin)
|
||
|
|
25: Asking for networkstatus consensus
|
||
|
|
REQUESTING_STATUS
|
||
|
|
(circuit_send_next_onion_skin)
|
||
|
|
30: Fetching networkstatus consensus
|
||
|
|
LOADING_STATUS
|
||
|
|
(update_consensus_networkstatus_downloads)
|
||
|
|
50: Fetching relay descriptors
|
||
|
|
LOADING_DESCRIPTORS
|
||
|
|
(update_router_have_minimum_dir_info)
|
||
|
|
80: Connecting to entry guard
|
||
|
|
CONN_OR
|
||
|
|
(update_router_have_minimum_dir_info)
|
||
|
|
85: Finishing handshake with entry guard
|
||
|
|
HANDSHAKE_OR
|
||
|
|
(connection_or_finished_connecting)
|
||
|
|
90: Establishing circuit
|
||
|
|
CIRCUIT_CREATE
|
||
|
|
(circuit_send_next_onion_skin)
|
||
|
|
100: Done
|
||
|
|
|