commit 0c14d27563e6cfb24ee2a11457f8b64b80512259 Author: Roger Dingledine <arma@torproject.org> Date: Thu Feb 11 23:04:27 2016 -0500 tiny tweaks to proposal 255 after reading --- proposals/255-hs-load-balancing.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposals/255-hs-load-balancing.txt b/proposals/255-hs-load-balancing.txt index eaab035..a19949c 100644 --- a/proposals/255-hs-load-balancing.txt +++ b/proposals/255-hs-load-balancing.txt @@ -101,7 +101,7 @@ is the minimal amount of data required to process the INTRODUCE2 cell on another machine. Before proposal 224 is implemented, this could consist of the -INTRODUCE2 cell payload, the key to decrypt the cell with if the cell +INTRODUCE2 cell payload, the key to decrypt the cell if the cell is not already decrypted (which may be preferable, for performance reasons), and data necessary for other machines to recognize what to do with the cell. @@ -136,7 +136,7 @@ INTRODUCE2 cell arrives at the node which published the descriptor, it does not immediately try to perform the rendezvous, but instead outputs this to the controller. Through an out-of-band process this message is relayed to a controller of another node of Bob's, and this transmits -the "PERFORM-RENDEZVOUS" command to that node. This node finally +the "PERFORM-RENDEZVOUS" command to that node. This node performs the rendezvous, and will continue to serve data to Alice, whose client will now not have to talk to the introduction point anymore. @@ -155,3 +155,4 @@ and to leave the actual load-balancing algorithm to the implementor of the controller. The developer of the tor implementation should not have to choose between a round-robin algorithm and something that could pull CPU load averages from a centralized monitoring system. +