David Steere and Trevor Robinson: How Live Mesh P2P Syncing Works

Live Mesh's pub/sub model is conceptually a push model -- each device has a notification queue, the device can create subscriptions, and when a subscription generates an event (or another device or part of the Mesh needs to reach the device), that event is posted to the queue and the device gets it.

Because Live Mesh is designed to work across any network topology, we can't always ensure that the cloud will be able to push a notification down to an arbitrary client -- it might be behind a firewall, or NAT, or who knows what.  So instead, we have each client open up a single long-lived HTTP connection to the server.  If there are no new notifications, the request times out after 60 seconds, and then the client opens a new one.  When a new notification comes in, the cloud sends down in response to that open request from the client.  You might have heard this technique referred to as Comet or full-duplex AJAX.

I think David mentioned this in the video...we use the cloud to store all the metadata about a Live Folder (the filenames, change history, etc).  Each client synchs metadata with the cloud, which produces a list of files that are out of date on the client.  Then the client can fetch those files from anyone else who has them.  In your case, if the cloud doesn't have the files, we will fetch them from another client.  For now, we don't have a lot of client location and optimization in place, so the client is equally happy to fetch the file from the cloud (if it's there), from a client somewhere outside your LAN, or a client on the LAN.  We are working on putting more intelligence in here.

we are certainly thinking about this, yes.  There are a lot of scenario in which the easiest path is for client developers to write against the APIs that our platform will provide (see http://channel9.msdn.com/posts/Dan/Ori-Amiga-Programming-the-Mesh/ ).