VT2016 DDP

From air
Revision as of 20:38, 27 November 2016 by Xueyong.Qian (talk | contribs) (→‎DDP)
Jump to navigation Jump to search

Presentation

  • Sujet : DDP
  • Auteur : Xueyong QIAN
  • Enseignants : Didier Donsez, Georges-Pierre Bonneau
  • Date : 27/11/2016

Résumé

DDP est un acronyme pour Distributed Data Protocol. C'est le protocole que Meteor(A full-stack JavaScript framework) utilise pour communiquer entre le client et le serveur. Techniquement, DDP peut être implémenté sur tout transport en duplex. L'implementation actuelle de Meteor est sur WebSockets et SockJS. SockJS est un transport d'émulation de WebSockets, qui peut être utilisé lorsque WebSockets n'est pas disponible.

  • Mots-clés : Meteor, DDP, JavaScript, WebSockets


Abstract

DDP is an acronym for Distributed Data Protocol. It’s the protocol Meteor(A full-stack JavaScript framework) uses to communicate between the client and the server. Technically, DDP can be implemented on top of any duplex transport. Meteor’s current implementation is based on WebSockets and SockJS. SockJS is a WebSockets emulation transport, which can be used when WebSockets is not available.

  • Keywords : Meteor, DDP, JavaScript, WebSockets

Synthèse

Meteor

Meteor is a full-stack Javascript Framework

DDP

What is DDP?

DDP is the heart of MeteorJS and it’s the protocol Meteor uses to communicate between the client and the server. DDP is an acronym for Distributed Data Protocol. Meteor has implemented both client and server implementations for DDP.

What does DDP do?

DDP mainly does two things:

  • It handles Remote Procedure Calls (RPC).
  • It manages data.

Handling Remote Procedure Calls

With RPC, you can invoke a method on the server and get something back in return. Besides that, DDP has a nice feature: it notifies the caller after all the write operations in the method have been reflected to all the other connected clients.

  • The DDP client (arunoda) invokes the method transferMoney with three parameters: 1000USD, arunoda and sacha.
  • Then after the transfer has been accepted, the DDP server (bank) sends a message with an updated balance to arunoda’s account. The balance is in the result field. If there was an error, there will be an error field instead of the result.
  • Some time later, the DDP server sends another message called updated with the method id, notifying me that my transfer has been sent to sacha successfully and he has accepted it. Sometime, updated message comes before the result. (It’s also possible to receive updated message even before the result message)

Handling Remote Procedure Calls

This is the core part of the DDP protocol. A client can use it to subscribe into a real-time data source and get notifications. The DDP protocol has three types of notification: added, changed and removed. Since the DDP protocol was inspired by MongoDB, each data notification (a JSON object) is assigned to a collection, which is the place where the data belongs.

Let’s look at an example.

We’ve a data source called account, which holds all the transactions made by the users. In this example, sacha will connect to his account to get his transactions. After arunoda makes a transfer, sacha will receive the new transaction. Here’s the data flow for this:

  • The DDP client (sacha) sends a subscription request for his account.
  • He will receive a couple of added notifications with the current transactions in his account.
  • After all the transactions have been sent by the DDP server (bank), DDP will send a special message called ready. The ready message indicates that all the initial data for the subscription has been sent and you are good to go.
  • Some time later, after arunoda has sent his transfer, sacha will receive the transaction as another added notification.

Bibliographie