 |
|||||||||
|
|||||||||
|
|
In the past couple of posts on peer networking , I've been doing a lot of talking about how amazingly powerful peer networks are and how much more compelling your applications can be if you make them aware of their peers, whether those peers are other instances of the same app, or instances of a companion application elsewhere on the network. I've talked about the means by which you can peer-enable your applications: discovery and publication systems like Bonjour and PNRP and peer programming APIs like the WCF Peer Channel. I have even talked briefly about sharing state in a peer network and I even have an upcoming MSDN Magazine article (July issue) on that very topic, which includes code samples.
What I haven't talked about is where peer network applications fall short. If you've been following along throughout the peer networking series, you might have noticed a potential use case/scenario that is very common but is completely ignored by all of the peer networking technology that I've discussed so far. Here is that scenario:
Let's say you have an application that allows you to track bank transactions. You want this application to also share those transactions with anybody else on the family's home network. This allows you to log all your receipts for the day and have them show up on your computer and anybody else's computer that is running the application. There are a lot of techniques to make this happen, and everything seems to be working great. Now picture this - you log into the application and log a few hundred dollars worth from your latest Best Buy spending spree. You shut your computer off. Your wife then logs into her version of the app and logs the expenses from her latest trip to Macy's and then shuts her computer off. The two of you go about this same behavior for the next week until finally your bank balance drops below 0 and a huge fight ensues.... Why? What happened? None of your transactions ever made it to your wife's application and none of hers ever made it to yours. This is the core limitation of peer networking technology for modern applications:
All pure peer networking architectures require that at some point, at least two peers be connected to the mesh at the same time for the application to work properly. Data cannot be synchronized and state cannot be shared when all nodes connect at different times and never speak to each other.
So when you're thinking about building your application and you're thinking about peer-enabling it, you absolutely, positively, must consider the scenario where for an extended period of time, no two nodes in your peer mesh are ever connected at the same time. If this has little to no impact on your application, then you are safe using nothing but peer communication systems like the WCF PeerChannel. However, if this will break your application or cause a perceived failure on the part of the end user (or worse, a huge fight over money and bills!) then you need to build some kind of mechanism on top of the peer network that allows you to swap/share data even when the nodes in the mesh are never connected at the same time.
Is there a solution? What can you do about this? There are many solutions, most of which require a ridiculous amount of coding...but the solution I'm going to talk about in my next post is Live Mesh. See, you were wondering when I was going to get around to talking about Live Mesh... stay tuned!
