|
|
Overview
This document gives a short overview of the project.
How does DDNS work ?
This figure gives you a clue how DDNS works.
You share your data with other peers and in return you share your CPU power (you "pay" for your shared data with CPU power). Everyone can query the network (without sharing data and CPU power).
P2P technology
DDNS is based on a distributed hash table (DHT). There are several other ways to implement a P2P system. DDNS is a DHT because data is found in O(log n). A broadcast is much worse and produces a lot of traffic.
The next 2 figures shows the difference :
Broadcast

DHT

DDNS is based on the Kademlia (Kademlia) protocol, which uses an XOR metric. One of the disadvantages of DDNS to a hierarchical DNS is lookup performance.
A DDNS needs more RPCs and thus more traffic. To keep the traffic as low as possible the symmetric lookup algorithm is used.
Communication
The DDNS system hast two important RPC: get and store. First, we take a look at the get RPC. We need to modify this RPC to make DDNS stable.

DDNS always waits for more than one result. Only this way can ambiguous data be recognized. The majority has always right and ambiguous data are corrected. The rule for ambiguous data is "first come, first served". So the first entry has the higher priority.
The store RPC is a bit more complex. In order to share your data, you have to share your
CPU power.

A third node sends node 2 an mvm package that node 2 has to execute. After node 2 has done all calculations, node 2 sends the result back to the third node and sends a digest back to node 1. This way, you can prevent an "insertion DoS". The storage of a name is a scarce resource.
The problem is that a malicious node can send back any results. So we must send the same package twice. This figure show an even more complex but detailed communication.

There are several other features to identify malicious clients. You can take a look at the source code to get a deeper insight into these features.
|