The term ‘peer’ or more commonly ‘peer to peer’ leads people to think about sharing and collaboration scenarios. That’s good. One of the most common peer to peer applications that quickly jumps to mind is file sharing which became rather popular in the recent years and led to illegal sharing of copy righted material which resulted in large number of law suits that you are well aware of. That’s the bad part. This kind of thought when comes to mind discourages people from exploring the technology and uncovering its strength. My feel is that you won’t fall in this unfortunate trap and I am just plain wrong.
Let me tell you the main scenarios for which DbPeerSyncProvider is a key enabler:
Two people in a project could exchange information between each other’s without the need for a third node or, in other words a server node. In this kind of setup, data flows in multiple directions and loops are likely to occur between different members of the project. By that I mean, P1 sync changes with P2, P2 sync changes with P3, and P3 sync changes with P1. In collaboration scenarios multiple people are working on the same resources and synchronize their changes between each others. A server node is not required in this scenario but typically added for centralized backup and reporting needs.
When the load increases on your server, you would typically upgrade your server to more powerful one. Buy more RAM, change the processor, or even replace the machine altogether. These are different types of scaling up your system. But if you get a new machine and add it to the existing server such that the load is distributed on both, then that is scale out.
While DbServerSyncProvider scalability is limited to scale up techniques, DbPeerSyncProvider gives you scale out architecture that you might be looking for. In scale out scenarios, your client sync applications are not talking to each others, they are not synchronizing peer-to-peer, they only talking with the server. However, the server is not a single machine any more. It could be a server farm with some scheme of distributed load balancing. Changes on one server are synchronized with the other servers in peer to peer fashion using DbPeerSyncProvider. The client application too will have to use DbPeerSyncProvider despite that fact that it is only synchronizing data with the server.
This is a fascinating setup and not so obvious especially when all we talk about is peer-to-peer sync. Many variations of these two key scenarios are definitely possible. It is all up to your imagination.
Update: Just to let you know, I left Microsoft to start a new company, Raveable Hotel Reviews. See examples: Romantic Hotels in NYC, Best Hotels in Seattle, Top 10 Hotels in Myrtle Beach, Kid Friendly Hotels in Chicago, and Best Hotels in Miami. Your feedback is welcome on twitter.com/raveable
I am not actively blogging about Sync Technologies. Please see Sync Team Blog for more updated content.