From d4c9210a4e44287b82a175377c8d13a6e4ce0b45 Mon Sep 17 00:00:00 2001 From: Brian Warner Date: Sun, 1 Jul 2018 17:03:57 -0700 Subject: [PATCH] more docs updates --- docs/dilation-protocol.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/dilation-protocol.md b/docs/dilation-protocol.md index ab5b50b..e7a90bd 100644 --- a/docs/dilation-protocol.md +++ b/docs/dilation-protocol.md @@ -37,8 +37,8 @@ L1 is the mailbox channel (queued store-and-forward messages that always go to the mailbox server, and then are forwarded to other clients subscribed to the same mailbox). Both clients remain connected to the mailbox server until the Wormhole is closed. They send DILATE-n messages to each other to manage -the dilation process, including records like `please-dilate`, -`start-dilation`, `ok-dilation`, and `connection-hints` +the dilation process, including records like `please`, `connection-hints`, +`reconnect`, and `reconnecting`. L2 is the set of competing connection attempts for a given generation of connection. Each time the Leader decides to establish a new connection, a new @@ -155,16 +155,17 @@ attempts and terminate any existing connections (even if they appear viable). Listening sockets may be retained, but any previous connection made through them must be dropped. -Once all connections have stopped, the Follower should send an `ok` message, -then start the connection process for the next generation, which will send -new `connection-hint` messages for all listening sockets). +Once all connections have stopped, the Follower should send an `reconnecting` +message, then start the connection process for the next generation, which +will send new `connection-hint` messages for all listening sockets). Generations are non-overlapping. The Leader will drop all connections from generation 1 before sending the `reconnect` for generation 2, and will not -initiate any gen-2 connections until it receives the matching `ok` from the -Follower. The Follower must drop all gen-1 connections before it sends the -`ok` response (even if it thinks they are still functioning: if the Leader -thought the gen-1 connection still worked, it wouldn't have started gen-2). +initiate any gen-2 connections until it receives the matching `reconnecting` +from the Follower. The Follower must drop all gen-1 connections before it +sends the `reconnecting` response (even if it thinks they are still +functioning: if the Leader thought the gen-1 connection still worked, it +wouldn't have started gen-2). (TODO: what about a follower->leader connection that was started before start-dilation is received, and gets established on the Leader side after @@ -181,19 +182,18 @@ connection attempts and having an established connection) starting with the receipt of a `please-dilate` message and a local `w.dilate()` call. The Leader remains in that state until it abandons the connection and sends a `reconnect` message, at which point it remains in the "flushing" state until -the Follower's `ok` message is received. The Follower remains in "connecting" -until it receives `reconnect`, then it stays in "dropping" until it finishes -halting all outstanding connections, after which it sends `ok` and switches -back to "connecting". +the Follower's `reconnecting` message is received. The Follower remains in +"connecting" until it receives `reconnect`, then it stays in "dropping" until +it finishes halting all outstanding connections, after which it sends +`reconnecting` and switches back to "connecting". "Connection hints" are type/address/port records that tell the other side of likely targets for L2 connections. Both sides will try to determine their external IP addresses, listen on a TCP port, and advertise `(tcp, external-IP, port)` as a connection hint. The Transit Relay is also used as a (lower-priority) hint. These are sent in `connection-hint` records, which can -be sent by the Leader any time after the `start-dilation` record, and by the -Follower after the `ok-dilation` record. Each side will initiate connections -upon receipt of the hints. +be sent any time after both sending and receiving a `please` record. Each +side will initiate connections upon receipt of the hints. ``` { "type": "connection-hints",