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.

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" protocol #312

warner opened this Issue Oct 16, 2018 · 2 comments


None yet
2 participants
Copy link

warner commented Oct 16, 2018

The "Dilation" protocol is a new way to manage the encrypted bulk-data pipe, which we use to do the actual file-transfer, replacing the current "Transit" protocol.

We first run the "wormhole" protocol to negotiate a session key and exchange some setup messages, then we switch over to Transit. When Dilation is implemented, the bulk-data pipe will be a part of the Wormhole object, rather than being an entirely separate thing.

I've been stuck at 80% on the protocol implementation for a long time now (the dilate-4 branch is my current work). I still intend to get it wrapped up and built, of course. But there are a lot of other issues that will become much easier to solve once Dilation is in place, so I wanted to create this ticket to keep track of my progress and to collect some design notes.


This comment has been minimized.

Copy link

joshtriplett commented Oct 16, 2018

I'd love to see this. (Posting to add myself to CC.)

warner added a commit that referenced this issue Dec 25, 2018

Merge branch 'dilate-5'
This adds (but does not enable/expose) the low-level code for the new
Dilation protocol (refs #312). The spec and docs are done, the unit tests
pass (with full branch coverage).

The next step is to write some higher-level integration tests, which use a
fake/short-circuited mailbox connection (Manager.send) but real localhost TCP

Then we need to figure out backwards compatibility with non-dilation-capable
versions. I've got a table in my notes, I'll add it to the ticket.

This comment has been minimized.

Copy link

warner commented Dec 25, 2018

Ok, that lands the low-level protocol. The w.dilate() method is disabled but if you remove the raise then who knows, it might actually work (I have unit tests for the low-level stuff, but I haven't tried to exercise dilate() yet).

The next steps are to write the higher-level tests, fix what breaks, and then start thinking about backwards-compatibility signalling with older versions. Basically we have a matrix where each side can be one of:

  • old client, trying to send a file/directory/etc
  • old client, willing to receive a file
  • new client, told to send just one file
  • new client, told to receive just one file
  • new client, told to establish a connection and then send arbitrary things in either direction (GUI mode)

Anything involving an old client must use the old Transit protocol, but if both sides are new then we should use Dilation instead. GUI mode requires Dilation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment