Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dilation #34

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

Dilation #34

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
2b9a8dd
please-dilate -> please as that is what the code says
vu3rdd Aug 10, 2022
1a3a84b
use-version is no longer used in the code
vu3rdd Aug 10, 2022
63507bf
Merge branch 'main' into dilation
piegamesde May 24, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 15 additions & 13 deletions dilation-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -47,28 +47,30 @@ Currently there is only one version: `"1"`.
## Leaders and Followers

Each side of a Wormhole has a randomly-generated dilation `side` string (this
is included in the `please-dilate` message, and is independent of the
piegamesde marked this conversation as resolved.
Show resolved Hide resolved
is included in the `please` message, and is independent of the
Wormhole's mailbox "side"). When the wormhole is dilated, the side with the
lexicographically-higher "side" value is named the "Leader", and the other
side is named the "Follower". The general wormhole protocol treats both sides
identically, but the distinction matters for the dilation protocol.

Both sides send a `please-dilate` as soon as dilation is triggered. Each side
Both sides send a `please` as soon as dilation is triggered. Each side
discovers whether it is the Leader or the Follower when the peer's
"please-dilate" arrives. The Leader has exclusive control over whether a
"please" message arrives. The Leader has exclusive control over whether a
given connection is considered established or not: if there are multiple
potential connections to use, the Leader decides which one to use, and the
Leader gets to decide when the connection is no longer viable (and triggers
the establishment of a new one).

The `please-dilate` includes a `use-version` key, computed as the "best"
version of the intersection of the two sides' abilities as reported in the
`versions` message. Both sides will use whichever `use-version` was specified
by the Leader (they learn which side is the Leader at the same moment they
learn the peer's `use-version` value). If the Follower cannot handle the
`use-version` value, dilation fails (this shouldn't happen, as the Leader
knew what the Follower was and was not capable of before sending that
message).
The version message payload has a key called `can-dilate` that has a
list of versions supported by a particular version of the client (eg:
["1", "2"]). After receiving the version message from the other
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This kind of gets rid of how the negotiation actually happens .. can we leave the use-version and versions details (i.e. it no longer says how to compute the "shared" versions or who decides which version to use and how that's communicated.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand your point, sorry

client, each client computes a list of mutually compatible "shared"
versions that are commonly supported by both the clients. At the
moment, the version number is "1", so if both the clients support that
version, we pick the dilation version as "1". If the clients cannot
find a mutually compatible version, then dilation would fail.



## Connection Layers

Expand Down Expand Up @@ -225,7 +227,7 @@ derived key)

Each side is in the "connecting" state (which encompasses both making
connection attempts and having an established connection) starting with the
receipt of a `please-dilate` message and a local `w.dilate()` call. The
receipt of a `please` 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 `reconnecting` message is received. The Follower remains in
Expand Down Expand Up @@ -484,7 +486,7 @@ that object.
Each time an L3 connection is established, the side will immediately send all
L4 messages waiting in the outbound queue. A future protocol might reduce
this duplication by including the highest received sequence number in the L1
PLEASE-DILATE message, which would effectively retire queued messages before
PLEASE message, which would effectively retire queued messages before
initiating the L2 connection process. On any given L3 connection, all
messages are sent in-order. The receipt of an ACK for seqnum `N` allows all
messages with `seqnum <= N` to be retired.
Expand Down