port Rendezvous machine

[warner]

https://github.com/warner/magic-wormhole/blob/0.10.5/src/wormhole/_rendezvous.py

Magic-wormhole uses a server to queue and deliver messages to the other client. Originally I called this the "Rendezvous Server", because it's a place where clients meet up. But that word was too long, so recently I've started calling it the "Mailbox Server", which makes its role a bit more obvious. The code for this server now lives in its own repo (https://github.com/warner/magic-wormhole-mailbox-server), but the client-side code still sometimes refers to it as "Rendezvous". This server owns the "Nameplate" and "Mailbox" data structures, and our client-side Nameplate/Mailbox machines deal specifically with these two structures, so we call the overall connection-management machine the "Rendezvous Machine".

(until we come up with a better name for it)

The Rendezvous machine manages the WebSocket connection to the server. It knows whether we want one or not (we always want one until w.close() is called), whether we have a connection or not, and reconnects after a short random delay after it drops (to avoid the "thundering herd" problem). It also sends the BIND message upon connect, and formats all other server messages on behalf of the other machines (e.g. it knows how to format the Add message which Send transmits, and the Claim message that Nameplate generates).

It also handles inbound messages, by parsing them into a type (Claimed, Nameplates, Message, etc), and delivering them to their appropriate machines.

It also records debug/timing information. Each message to the server includes a short random id value, and the server responds with an ack message that copies the ID. The messages also include server_tx with a timestamp of when the server sent it. This allows port-mortem timing analysis (see https://github.com/warner/magic-wormhole/blob/0.10.5/misc/dump-timing.py) to find ways to speed things up.

The Python code delegates a lot of the connect-lose-wait-reconnect logic to a Twisted class named ClientService, so the python Rendezvous object doesn't really have a state machine. The picture above shows what it would basically look like, if we had one. So we'll need to build one and replicate a lot of the ClientService functionality.

Rendezvous is (currently) the only machine that performs any IO. In our sans-io model, it does this by emitting "IO Actions", which are events that get delivered to the API/IO glue layer, with names like "start timer" and "open websocket connection". That layer then figures out some way to perform the requested action, and delivers "IO Events" when they finish (like "timer expired", "connection made", and "data received"). There are handles to associate the Events with the Action that provoked them.

[warner]

This is pretty much done