Communicating between MEWAs within a Mesh - High and Low Latency Options

Question

Scenario: I've got a bunch of people using an application within a Mesh. They are not always connected at the same time, but the application requires them to have a live connection (if it can't reach Azure Storage, the app will terminate, for reasons that aren't relevant to this post).

High Latency: There are actions that people take within the application that need to propagate within the Mesh, but I don't particularly care how long it takes, which makes the use of Feeds just fine because these can take a (relatively) long time to migrate from one machine to another. I can use the standard feed entry changed subscription thing (assuming the performance gets fixed) to alert all the other connected MEWAs of the change in the feed.

Low Latency: Other actions that people take within the application need to happen quickly. I need very low latency between when the action takes place and when the other client(s) are notified about the action. Think of these as instant messages, though with a domain-specific purpose. Some can be directed at an individual MEWAs, others can be broadcasts. I do not currently have a solution for the low latency.

I know that Silverlight applications cannot receive push messages because of their highly restricted network Sandbox. However, I'm wondering if they would be able to create an HTTP WCF service via .NET Services and host the proxy in the cloud that would allow near-real-time HTTP message posting between MEWAs... Is this possible?

---

The .NET Addict - http://dotnetaddict.dotnetdevelopersjournal.com

Answer 1

Have you seen the notifications topic, http://msdn.microsoft.com/en-us/library/dd199393.aspx?


doug

Answer 2

Yes, being notified of feed changes is what i referred to as high latency - it's stuff that occurs at such a low rate of update that I don't particularly care how long it takes for the notification to arrive. Notifications can take an indeterminate amount of time to propagate to other users of the Mesh.

What I don't have a solution for is low-latency (<1 second) between the time the event occurred and the time that another Silverlight MEWA is notified about the change. Essentially I want the functionality I can get with the Service Bus HTTP-mode NetEventRelay binding, but available to a MEWA.

---

The .NET Addict - http://dotnetaddict.dotnetdevelopersjournal.com

Answer 3

I wonder when or if we'll see general-purpose functionality exposed that enables us to build the equivalent of www.mesh.com's remote desktop communication.  I think there will be more P2P APIs exposed to us at some point (taking advantage of MSN Messenger P2P protocols I believe) but it will be interesting to see just how much will be exposed and how Silverlight/JavaScript-friendly it will be.  And will it be point-to-point, pub-sub, or what?  How will user and/or device presence be exposed?  Will we be able to establish ad-hoc connections as well as Member/Mapping-based connections?  Will it be optimized for low-latency chat, or high-throughput streaming?  I'm guessing the real-time communication programming model won't be feed-based, but I could be wrong.

Answer 4

Kevin,

Thank you for posting wonderful question and an interesting scenario.

As of now latency is something that your app cannot control tightly. Everything is based on the three models listed below:

1) Your App connects to the cloud endpoint explicitly (https://user.windows-ctp.com) and this requires an ISV promoting Rich Client kinda app model (companion to web sites) - almost real time story
2) Your App connects always to a local endpoint and it relies on LOE synchronization between local and cloud mesh data - hugging offline philosophy (leave syncup cycles to LOE)
3) You choose MEWA and rely on underlying out-of-the-box infrastructure related to sharing, synchronization and permission sets - middle approach with pros and cons (your app has to fit the model)

As of now, LOE (local) has baked in latency into its configuration. If you run fiddler, you can figure out easily that mesh runtime initiates contact with the cloud periodically (sounds like every 30 secs) if connected to internet.

As soon as your app model/architecture makes a choice about offline capability then it implicity accepts latency. Here near real-time (factor varies per app and is not universal standard) scenario is an inversely proportional preposition.  The practical way to avoid is to build client-to-web meshified apps.

One more thing, LOE fully encapsulates the communications. Example it can use P2P to sync up devices within the vicinity without involving clouds for round trips.

Hope this helps,

Rajan

---

(This post is provided "AS IS" with no warranties, and confers no rights.)

Answer 5

Oran/Kevin,

If you exclude MEWA (as they are unique kind of apps with sandbox and specific app model including hosted deployment lifecycle management), then you can leverage other services like Internet Service Bus to integrate into your applications with sub-pub semantics and meshification as one portion of the grand strategy to leverage users, devices, data and applications. Here you have a better flexibility in terms of architecture, services and integration as well as choices.

This also brings another highly interesting topic i.e. limitation of meshobjects in MEWA (as app itself are meshobjects). As you know delAuth and MEWA does not allow creation of meshobjects but client-to-web can access all feeds (devices, meshobjects etc.) and can easily manage it on behalf of an end-user if he trust the ISV/app provider.

As you know well, anything  that  is Real-Time - it is challenging from various perspectives 1) Scalability 2) Intrusive nature in social context 3) expensive 4) Performance after some point 5) Induces Brittleness

Now if we are talking about almost realtime over loosely coupled systems then it is an interesting scenario with its core fundamentals and limitations around the possibilities for implementation scenarios.

Hope this helps. I would love to hear your comments and other scenarios related to this interesting topic.

Thank you,

Rajan

---

(This post is provided "AS IS" with no warranties, and confers no rights.)

Answer 6

All very good comments. As you mention, LOE is baked in with latency. As an LOE developer, I need to have it baked into my consciousness that a change that I make to a MeshObject/Feed/Entry could take a statistically significant amount of time to propagate to other client applications. This means that I need to try and stay away from storing things in feed entries that are finite sets of state rather than deltas... it's just "easier" that way.  The fact that I know this and am aware of it when architecting my applications means I won't step into some avoidable design and implementation pitfalls.

I know that there are some limitations to MEWAs as well - they can't see outside their own MeshObject (apparently this can be mitigated by manually granting other MOs permission, but I don't want my customers to have to do that...it's annoying and just feels "hacky"). Also, they can't receive incoming network connections or host their own open sockets, and they can't access things outside their own sandbox. The plus side, however, is that they're cross-platform.

I'm not looking for real-time over the Internet as there are just too many variables to control. However, as you said, "almost realtime over loosely coupled systems" - that's the stuff that keeps me awake at night. If I can have a WPF application that creates its own Mesh object, allows users to invite others into that Mesh object (who are also running that WPF app) - then some interesting possibilities occur where I can have an application that is using the Net Event Relay from the ServiceBus to pub/sub communicate among WPF clients while still using the Mesh for things that the Mesh is best at - data that needs to be synchronized and shared but can be shared in a "lazy" fashion.

---

The .NET Addict - http://dotnetaddict.dotnetdevelopersjournal.com

Answer 7

Yes, your understanding and differentiation is abosultely correct about advantages, limitations and flexibility offered by the two models (i.e. MEWA and Rich Apps/WPF).

In the future, there may be few things (I have seen in fact more than dozen settings) that could give you relatively better choice, flexibility and ability to control MEWA while configuring the application manifest. Latency could be one of them. Right now, dev does not want to bring out too many factors in this CTP so that we are focussed based on real world scenarios, demands and impact for prioritization.

Best,

Rajan

---

(This post is provided "AS IS" with no warranties, and confers no rights.)

Answer 8

Also, Kevin you can watch the following session if you are building WPF apps then you can subscribe change notifications:

http://channel9.msdn.com/pdc2008/BB34/


This could help your app as your meshobjects or feeds are changed across many devices or users.

One more thing, you can also leverage SyncEntries that are very similar to DataEntries but are annotated with FeedSync metadata as well as full version history for conflict detection.

Thanks,

Rajan

---

(This post is provided "AS IS" with no warranties, and confers no rights.)