aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2012-09-07 18:04:41 -0400
committerGravatar Joey Hess <joey@kitenet.net>2012-09-07 18:04:41 -0400
commit38c679d0c83285096051267b6428e1851c80247a (patch)
treee11bb627c12f2b5579a79307f9e34334a0f2e744 /doc
parentc28b54c4691f5a5dcab0411fb07e5b1d83565683 (diff)
blog for the day
Diffstat (limited to 'doc')
-rw-r--r--doc/design/assistant/blog/day_75__zeromq_and_pairing.mdwn50
1 files changed, 50 insertions, 0 deletions
diff --git a/doc/design/assistant/blog/day_75__zeromq_and_pairing.mdwn b/doc/design/assistant/blog/day_75__zeromq_and_pairing.mdwn
new file mode 100644
index 000000000..9f2ba4816
--- /dev/null
+++ b/doc/design/assistant/blog/day_75__zeromq_and_pairing.mdwn
@@ -0,0 +1,50 @@
+Started reading about ZeroMQ with the hope that it could do some firewall
+traversal thing, to connect mutually-unroutable nodes. Well, it could, but
+it'd need a proxy to run on a server both can contact, and lots of
+users won't have a server to run that on. The XMPP approach used by
+dvcs-autosync is looking like the likeliest way for git-annex to handle
+that use case.
+
+However, ZeroMQ did point in promising directions to handle another use
+case I need to support: Local [[pairing]]. In fairly short order, I got
+ZeroMQ working over IP Multicast (PGM), with multiple publishers sending
+messages that were all seen by multiple clients on the LAN (actually the
+WAN; works over OpenVPN too). I had been thinking about using
+Avahi/ZeroConf for discovery of systems to pair with, but ZeroMQ is rather
+more portable and easy to work with.
+
+Unfortunatly, I wasn't able to get ZeroMQ to behave reliably enough.
+It seems to have some timeout issues the way I'm trying to use it,
+or perhaps its haskell bindings are buggy? Anyway, it's really overkill
+to use PGM when all I need for git-annex pairing discovery is lossy
+UDP Multicast. Haskell has a simple `network-multicast` library for that,
+and it works great.
+
+With discovery out of the way (theoretically), the hard part about
+[[pairing]] is going to be verifying that the desired repository is being
+paired with, and not some imposter. My plan to deal with this involves a
+shared secret, that can be communicated out of band, and HMAC. The webapp
+will prompt both parties to enter the same agreed upon secret (which could
+be any phrase, ideally with 64 bytes of entropy), and will then use it as
+the key for HMAC on the ssh public key. The digest will be sent over the
+wire, along with the ssh public key, and the other side can use the shared
+secret to verifiy the key is correct.
+
+The other hard part about [[pairing]] will be finding the best address to
+use for git, etc to connect to the other host. If MDNS is available, it's
+ideal, but if not the pair may have to rely on local DNS, or even
+hard-coded IPs, which will be much less robust. Or, the assistant could
+broadcast queries for a peer's current IP address itself, as a poor man's
+MDNS.
+
+All right then! That looks like a good week's worth of work to embark on.
+
+---
+
+Slight detour to package the haskell network-multicast library and upload
+to Debian unstable.
+
+Roughed out a data type that models the whole pairing conversation,
+and can be serialized to implement it. And a state machine to run
+that conversation. Not yet hooked up to any transport such as multicast
+UDP.