I hope I'm nearly at the end of this XMPP stuff after today. Planning a new release tomorrow.


Split up the local pairing and XMPP pairing UIs, and wrote a share with a friend walkthrough.


Got the XMPP push code to time out if expected data doesn't arrive within 2 minutes, rather than potentially blocking other XMPP push forever if the other end went away.

I pulled in the Haskell async library for this, which is yes, yet another library, but one that's now in the haskell platform. It's worth it, because of how nicely it let me implement IO actions that time out.

[[!format haskell """ runTimeout :: Seconds -> IO a -> IO (Either SomeException a) runTimeout secs a = do runner <- async a controller <- async $ do threadDelaySeconds secs cancel runner cancel controller after waitCatch runner """]]

This would have been 20-50 lines of gnarly code without async, and I'm sure I'll find more uses for async in the future.


Discovered that the XMPP push code could deadlock, if both clients started a push to the other at the same time. I decided to fix this by allowing each client to run both one push and one receive-pack over XMPP at the same time.


Prevented the transfer scanner from trying to queue transfers to XMPP remotes.


Made XMPP pair requests that come from the same account we've already paired with be automatically accepted. So once you pair with one device, you can easily add more.

Joey, How does pairing on the local network work btw? Now that you have experience intercepting and relaying the git pack output maybe you can use UDP broadcast on the local network for a truly fast sync. With dropbox, I'm often syncing working copies of software projects between several VMs so I can test the code on all platforms before committing. I've found that to be faster (for builds) then using a VM shared folders, network shares, etc.

Developing something new based on IPv4 UDP broadcast seems to be insane. IPv6 link-local multicast should be available virtually anywhere. XMPP relies on TCP and a central server to guarantee that a single packet is not split up, which would need quite some protocol engineering to get right over lossy UDP (e.g. segmentation, flow control, congestion avoidance). But TCP as discovered using mDNS might work… Still needs some kind of authentication / encryption, though.
Comment by http://phil.0x539.de/ Mon Nov 12 11:50:42 2012

Also, you probably know about Jingle: http://en.wikipedia.org/wiki/Jingle_(protocol)

What are you thoughts about it? I guess it would have been harder to use the Google C++ library from Haskell and full mesh peer-to-peer is certainly more complicated than using the XMPP server to effectively multicast to all paired clients.

Alright, I stand corrected, although I'm aware of some libraries that have already solved the problem so you don't really have to implement reliable UDP from scratch: http://code.google.com/p/openpgm/

To quote the website (emphasis mine):

PGM is appropriate for applications that require duplicate-free multicast data delivery from multiple sources to multiple receivers. PGM does not support acknowledged delivery, nor does it guarantee ordering of packets from multiple senders.

Comment by http://phil.0x539.de/ Mon Nov 12 12:50:26 2012
For local pairing, multicast UDP is used for discovery and authentication, and then all data transfers take place over ssh.
Comment by http://joeyh.name/ Mon Nov 12 14:43:32 2012
Comments on this page are closed.