Feature request: Real-time P2P messaging

Question

I would like Live Framework to provide real-time P2P messaging between users, apps, and devices.  I have written a blog post describing what I'm looking for, with scenarios and ideas on what such a feature might look like.

I know others have asked for such a feature before, so if this is something you'd like to see, please vote on the Connect suggestion.

If you can think of additional scenarios for this feature (and I'm sure you can), please list them here, along with feedback on what you like and don't like.  If you think of alternate solutions, please share those too.

---

http://orand.blogspot.com

Answer 1

Good to know that I'm not the only person who wants this. Right now we are so close to being able to do this that all it would take is a little bit of extra push from Microsoft to get it done.

Think about it this way: Today, our Silverlight 2 applications can receive psuedo-push data from their back-end web servers thanks to the WCF silverlight-custom duplex channel. Silverlight 2 apps can also "passively poll" on a socket connection, which is a little lower level, but faster and less bulky than the duplex channel.

Either of these solutions should be adaptable so that we can use a .NET Services (it's all about the Cloud, baby) ServiceBus channel to rig up a P2P channel between all running instances of my S/MEWA, allowing me to dynamically send data to those instances as well as allow users of those instances to talk to each other.

That said, I think the scenario in your blog post can be handled with good old fashioned non-mesh .NET stuff since an S/MEWA isn't going to be obtaining Wiimote-like input from a dongled Smartphone anytime soon, but a Mesh-enabled WPF would..but that same app has raw WCF P2P channels at its disposal and Bonjour for Windows if need be to discover other Kiosks, etc.

So yes, count me in on the list of people who want a high-speed P2P channel available for S/MEWA mesh-wide communication.

---

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

Answer 2

This would be a good feature. I voted for it.

---

Microsoft MVP - Windows Live Platform

Answer 3

 

Oran -

Thanks for the suggestion and the blog post backing it up.

When I first read about it I was a bit ambivalent because I am somewhat hesitant to break the purity of the AtomFeed model this early in the game. To some extent, MEWAs violate that purity as witnessed by the surprise when someone discovers that one MEWA is one MeshObject and the fact that they are not supported in the Live Mesh Beta.

However, on rereading Oran's blog I was struck by the scenarios he provided and think it an interesting proposal – so it will get my vote. Were something like this to happen I would hope it would be done inside the context of the current model by, for example, treating messages as entries on a feed which if memory serves .Net Services already does. But I would also hope that it would be done inside the Azure context by which I mean using the forwarding capabilities of .Net Services. It is pretty obvious from the PDC talks that the .Net Services people are putting a lot of effort into developing a fabric where this type of traffic is optimized and it would be a shame not to use it.

I bring this up because it does seem that you could almost roll your own version of this request using Live Mesh and .Net Services. I use the word almost because I don’t really know the limitations of MEWA and .Net Services well enough. This might be no more than a Live Framework style API on top of a .Net Services API. I agree that it would be easier for everyone if Microsoft provided this.

Indeed I would like to see deeper integration of the various parts of Azure over time. I think a big difficulty of thinking about possible application architectures just now is the lack of understanding of how the different Azure components will fit together. Someone using Azure Storage, for example, might want to use Live Mesh to provide local indexing capability into that storage while someone else, you, might want to use the messaging capabilities of .Net Services.

This raises the issue of pricing structure.  I see a lot of interest about pricing structure of individual parts of Azure and would hope that Microsoft pays some attention to the desire to integrate different parts of Azure into a single application or service. It would be a shame if people are forced into poor technical decisions because the pricing structure discouraged architectures like using .Net Services to handle messaging for a MEWA. Of course, that may be another reason to bake messaging into the LiveFX bits.