xxx-bootstrap-phases.txt 3.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106
  1. Filename: xxx-bootstrap-phases.txt
  2. Title: Keep controllers informed as Tor bootstraps
  3. Version: $Revision$
  4. Last-Modified: $Date$
  5. Author: Roger Dingledine
  6. Created: 07-Jun-2008
  7. Status: Open
  8. 1. Overview.
  9. Tor has many steps to bootstrapping directory information and
  10. initial circuits, but from the controller's perspective we just have
  11. a coarse-grained "CIRCUIT_ESTABLISHED" status event. Tor users with
  12. slow connections or with connectivity problems can wait a long time
  13. staring at the yellow onion, wondering if it will ever change color.
  14. This proposal describes a new client status event so Tor can give
  15. more details to the controller. Section 2 describes the changes to the
  16. controller protocol; Section 3 describes Tor's internal bootstrapping
  17. phases assuming everything goes correctly; and Section 4 describes
  18. how and when Tor chooses to issue bootstrap warnings.
  19. 2. Controller event syntax.
  20. The generic status event is:
  21. "650" SP StatusType SP StatusSeverity SP StatusAction
  22. [SP StatusArguments] CRLF
  23. So in this case we send
  24. 650 STATUS_CLIENT NOTICE/WARN BOOTSTRAP \
  25. PROGRESS=num TAG=string SUMMARY=string
  26. "Progress" gives a number between 0 and 100 for how far through
  27. the bootstrapping process we are. "Summary" is a string that can be
  28. displayed to the user to describe the *next* task that Tor will tackle,
  29. i.e., the task it is working on after sending the status event. "Tag"
  30. is an optional string that controllers can use to recognize bootstrap
  31. phases from Section 3, if they want to do something smarter than just
  32. blindly displaying the summary string.
  33. The severity describes whether this is a normal bootstrap phase
  34. (severity notice) or an indication of a bootstrapping problem
  35. (severity warn).
  36. 3. The bootstrap phases.
  37. Phase 0: tag=STARTING
  38. Phase 5: tag=CONN_DIR
  39. Phase 10: tag=HANDSHAKE_DIR
  40. Phase 15: tag=ONEHOP_CREATE
  41. Phase 20: tag=REQUESTING_STATUS
  42. Phase 25: tag=LOADING_STATUS
  43. Phase 40: tag=LOADING_KEYS
  44. Phase 45: tag=REQUESTING_DESCRIPTORS
  45. Phase 50: tag=LOADING_DESCRIPTORS
  46. Phase 80: tag=CONN_OR
  47. Phase 85: tag=HANDSHAKE_OR
  48. Phase 90: tag=CIRCUIT_CREATE
  49. Phase 100: tag=DONE
  50. 5: fetching authority key certs
  51. LOADING_KEYS
  52. (authority_certs_fetch_missing)
  53. 10: Connecting to directory mirror
  54. CONN_DIR
  55. (circuit_handle_first_hop)
  56. 15: Finishing handshake with directory mirror
  57. HANDSHAKE_DIR
  58. (connection_or_finished_connecting)
  59. 20: Establishing one-hop circuit for dir info
  60. ONEHOP_CREATE
  61. (circuit_send_next_onion_skin)
  62. 25: Asking for networkstatus consensus
  63. REQUESTING_STATUS
  64. (circuit_send_next_onion_skin)
  65. 30: Fetching networkstatus consensus
  66. LOADING_STATUS
  67. (update_consensus_networkstatus_downloads)
  68. 50: Fetching relay descriptors
  69. LOADING_DESCRIPTORS
  70. (update_router_have_minimum_dir_info)
  71. 80: Connecting to entry guard
  72. CONN_OR
  73. (update_router_have_minimum_dir_info)
  74. 85: Finishing handshake with entry guard
  75. HANDSHAKE_OR
  76. (connection_or_finished_connecting)
  77. 90: Establishing circuit
  78. CIRCUIT_CREATE
  79. (circuit_send_next_onion_skin)
  80. 100: Done