locked
Push synchronization RRS feed

  • Question

  • At the moment, Live Mesh takes about a minute or so to realize that there's a new file available to be downloaded from the server.  When Mesh is opened up to allow other types of applications (not just file sync), will this still be a limitation?  What is the architectural limit on how quickly "push" messages can be sent between nodes?  If I wanted to build a responsive IM app using Mesh, is that possible?
    Wednesday, July 2, 2008 6:00 PM

Answers

  • Synchronization in Live Mesh is currently driven based on notifications that are pushed down from the cloud to the client (I assume you're talking about the Live Mesh client software and not Live Desktop). It's odd that it takes a minute for this to show up on your system - more likely, the fact that a new file was available is noticed by Live Mesh immediately but it takes a while for the file to be pulled down (either through the cloud or P2P). You should see a .wlx file appear within 2-3 seconds which should then be converted to the actual file after download/sync is complete. For instance, if a file "Hello.jpg" is added to folder "Foo" on machine A, machine B (which has the folder mapped too) should show a file called "Hello.jpg.wlx" within a few seconds, and replace it with "Hello.jpg" when the file is downloaded.
    Live Desktop will, very shortly, also be using a notification-based solution.

    You should sign up for the SDK waitlist if you haven't already - details of how apps can leverage this mechanism will be published as part of the SDK when it's available. At a high level, the latency for a notification (what you call a message) to be created and routed to the recepient is in the order of milliseconds on the server side. There are multiple approaches available for notifications to be pushed to or pulled by a client, and end-2-end responsiveness will depend on the approach that an app takes. We are working to enhance this already rich notification system in the near future.

    Wednesday, July 2, 2008 6:54 PM
    Answerer

All replies

  • Synchronization in Live Mesh is currently driven based on notifications that are pushed down from the cloud to the client (I assume you're talking about the Live Mesh client software and not Live Desktop). It's odd that it takes a minute for this to show up on your system - more likely, the fact that a new file was available is noticed by Live Mesh immediately but it takes a while for the file to be pulled down (either through the cloud or P2P). You should see a .wlx file appear within 2-3 seconds which should then be converted to the actual file after download/sync is complete. For instance, if a file "Hello.jpg" is added to folder "Foo" on machine A, machine B (which has the folder mapped too) should show a file called "Hello.jpg.wlx" within a few seconds, and replace it with "Hello.jpg" when the file is downloaded.
    Live Desktop will, very shortly, also be using a notification-based solution.

    You should sign up for the SDK waitlist if you haven't already - details of how apps can leverage this mechanism will be published as part of the SDK when it's available. At a high level, the latency for a notification (what you call a message) to be created and routed to the recepient is in the order of milliseconds on the server side. There are multiple approaches available for notifications to be pushed to or pulled by a client, and end-2-end responsiveness will depend on the approach that an app takes. We are working to enhance this already rich notification system in the near future.

    Wednesday, July 2, 2008 6:54 PM
    Answerer
  • That is helpful - thank you.  I'm very glad to hear that you're going to allow different notification mechanisms.  For some applications, one would want immediate notification (like an instant messenger), while for others it's ok if the notification is delayed a minute or two--possibly in order to save on bandwidth/battery life/etc.

    Thanks.
    Wednesday, July 2, 2008 8:34 PM
  • Thanks Viraj.  This "push" point is vexing me.  From everything I have seen so far, it is still pull-based from the client doing polling every 25 seconds or so.  I probably have missed something.
    Thursday, July 10, 2008 3:40 AM