Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
Push-Pull Notify RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote
    How does notify work again at the lower level?  Does it push to connected client sockets or do the clients pull at intervals to get Notifications (events)?
    Abolade said in c9 video that there was also a distributed (in-memory) transient state system between all clients.  How does that work?  Is everything still store and forward or is transient state changes done in real-time with no store and forward. I heard they do use some IM tech, so I am guessing that is used for notifications, but not sure how this all fits. Is there a white paper yet on this arc.  If a C1 wants to notify C2 and C3, how would that work?

    TIA
    --William Stacey [c# mvp]
    Thursday, May 15, 2008 9:58 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote
    Thanks for your interest - these are great questions.

    The underlying server architecture supports pushing Notifications to connected clients, but the current implementation pulls down Notifications from the cloud. There are different types of Notifications, mapping to different events that may occur in the cloud. This Notification mechanism is what drives sycning of files, for instance.

    The in-memory transient state system that Abolade referenced is a non-persistent state store that's maintained in the cloud to represent the subset of client state that may change frequently (i.e. isn't persistent). These transient state systems drive a lot of the experiences around sync (finding endpoints to initiate a sync session from, inviting peers to sync, etc), for instance. We do not have a whitepaper about this architecture yet, but when we do it might help answer your question in more detail. Since this is a Tech Preview, we are iterating over the designs as we get feedback about the system.

    In addition to Abolade's video, check out Alex Mallet's blog entry @ http://blogs.msdn.com/livemesh/archive/2008/04/30/behind-live-mesh-how-we-run-cloud-services.aspx for some more high-level information on how we run our services.

    Thanks!
    Thursday, May 15, 2008 11:00 PM
    Answerer

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote
    Thanks for your interest - these are great questions.

    The underlying server architecture supports pushing Notifications to connected clients, but the current implementation pulls down Notifications from the cloud. There are different types of Notifications, mapping to different events that may occur in the cloud. This Notification mechanism is what drives sycning of files, for instance.

    The in-memory transient state system that Abolade referenced is a non-persistent state store that's maintained in the cloud to represent the subset of client state that may change frequently (i.e. isn't persistent). These transient state systems drive a lot of the experiences around sync (finding endpoints to initiate a sync session from, inviting peers to sync, etc), for instance. We do not have a whitepaper about this architecture yet, but when we do it might help answer your question in more detail. Since this is a Tech Preview, we are iterating over the designs as we get feedback about the system.

    In addition to Abolade's video, check out Alex Mallet's blog entry @ http://blogs.msdn.com/livemesh/archive/2008/04/30/behind-live-mesh-how-we-run-cloud-services.aspx for some more high-level information on how we run our services.

    Thanks!
    Thursday, May 15, 2008 11:00 PM
    Answerer
  • Question
    Sign in to vote
    0
    Sign in to vote
      Thanks for reply Viraj!  That helped.  I look forward to more info as it comes.  This will probably come together in my brain after we get some api bits and docs.  Thanks again.
    Thursday, May 15, 2008 11:59 PM