Distributed Database Protocol in Web Applications

Distributed Database Protocol in Web Applications Supports Algorithms and Protocols Rendering Them To Be More Sophisticated But Complex. There is not much written articles on Distributed Database Protocol. Even, Wikipedia failed to Copy properly. For the sake of creating a Page on Meteor (What is Meteor is written here), they ultimately ended up in this way :

Distributed Data Protocol (or DDP) is a client-server protocol for querying and updating a server-side database and for synchronizing such updates among clients. It uses the publish-subscribe messaging pattern. It was created for use by the Meteor Javascript framework.

Openly, Wikipedia is now discussing/voting on Paid content writing! Matt Cutts et al do not consider it to be a spam though.

No, the rewriting-logic-based language and tool Maude is well known and so is Distributed Data Protocol. So, what is this Distributed Database Protocol ?

DDP is a protocol between a client and a server that supports two operations:

1. Remote procedure calls by the client to the server.
2. The client subscribing to a set of documents, and the server keeping the client informed about the contents of those documents as they change over time.

 

Two-phase commit protocol for distributed databases can be formally modeled in an object-oriented way, simulated, and model checked in various system. The general techniques for modeling communication and site failures before modeling and analyzing demands an extension of that uses timeouts to re- quest retransmissions of lost messages.

Distributed database protocol has been not been analyzed much, despite the fact that the protocol’s simplicity makes it easy to understand the specification and analysis techniques. There is ample evidence that distributed database protocols  can be successfully applied to formally large and sophisticated systems.

DDP may use either SockJS or WebSockets as a lower-level message transport. DDP messages are JSON objects, with some fields specified to be EJSON.

 

Distributed Database Protocol versus Normal Git Push

 

Local deploy is mandatory for systems that uses Distributed Database Protocol. The localhost is a copy of the server instance. The procedure is :

1. The client specifies sets of information it is interested in by sending sub messages to the server.
2. At any time, but generally informed by the sub messages, the server can send data messages to the client. Data consist of added ,
   changed , and removed messages. These messages model a local set of data the client should keep track of.
3. An added message indicates a document was added to the local set. The ID of the document is specified in the id field, and the fields of the document are specified in the fields field. Database interprets the string id field in a special way that transforms it to the _id field of database documents.
4. A changed message indicates a document in the local set has new values for some fields or has had some fields
   removed.
5. The id field is the ID of the document that has changed. The fields object, if present, indicates fields in the document that should be replaced with new values. The cleared field contains an array of fields that are no longer in the document.
6. A removed message indicates a document was removed from the local set. The id field is the ID of the document.
7. A collection is either ordered, or not. If a collection is ordered, the added message is replaced by addedBefore , which
   additionally contains the ID of the document after the one being added in the before field. If the document is being added at the end, before is set to null.
8. For a given collection, the server should only send added messages or addedBefore messages, not a mixture of both, and should only send
   movedBefore messages for a collection with addedBefore messages.
9. The client maintains one set of data per collection.
10. Each subscription does not get its own datastore, but rather overlapping subscriptions cause the server to send the union of facts about the one collection’s data.
11. For example, if subscription A says document x has fields
    {foo: 1, bar: 2} and subscription B says document
    x has fields
    {foo: 1, baz:3} , then the client will be informed that document
    x has fields
    {foo: 1, bar: 2, baz: 3} . If field values from different subscriptions conflict with each other, the server should send one of the possible field values.

When one or more subscriptions have finished sending their initial batch of data, the server will send a ready message with their IDs.

 

Distributed Database Protocol : Further Reading

 

• [S. Chen, J. Meseguer, R. Sasse, H. J. Wang, and Y.-M. Wang. A systematic approach to uncover security flaws in GUI logic. In IEEE Symposium on Security and Privacy, pages 71“85. IEEE Computer Society, 2007.
• M. Clavel, F. Durn, S. Eker, P. Lincoln, N. Mart-Oliet, J. Meseguer, and C. Talcott. All About Maude – A High- Performance Logical Framework, volume 4350 of Lecture Notes in Computer Science. Springer, 2007.
• G. Denker, J. J. Garc ??a-Luna-Aceves, J. Meseguer, P. C. O ?lveczky,Y.Raju,B.Smith,andC.Talcott.Specification and analysis of a reliable broadcasting protocol in Maude. In B. Hajek and R. S. Sreenivas, editors, 37th Annual Allerton Conference on Communication, Control, and Computation. University of Illinois, 1999.
• A. Goodloe, C. A. Gunter, and M.-O. Stehr. Formal proto- typing in early stages of protocol design. In WITS™05. ACM Press, 2005.
• M. Katelman, J. Meseguer, and J. Hou. Redesigning the LMST wireless protocol by formal modeling and statistical model checking. In G. Barthe and F. de Boer, editors, For- mal Methods for Open Object-Based Distributed Systems (FMOODS™08), 2008. To appear.
• P.C.O ?lveczkyandS.Thorvaldsen.Formalmodelingand analysis of the OGDC wireless sensor network algorithm in Real-Time Maude. In M. M. Bonsangue and E. B. Johnsen, editors, Formal Methods for Open Object-Based Distributed Systems (FMOODS™07), volume 4468 of Lecture Notes in Computer Science, pages 122“140. Springer, 2007.