Prologue

Introduction Core Concepts Block Data & Operations Secure & Private by default User Cases Overall Workflow

Quick Start

Overview DNet Admin Overlay Cloud Provider End User

Run App on ĐNET

Run Tinc-VPN on ĐNET Tinc-VPN Introduction Tinc App Driver Tinc OVC Driver Data Files Folder DNetDB Structure Node Roles DNet Owner Node OVC Owner Node OVC Cloud Instance App User Node

Port App to ĐNET

Port Tinc-VPN to ĐNET Build From Source DNetDB CRUD OVC Implementation App Implementation App command line

Working with data

DNet Record OVC Record

Overall Workflow

The public data on blockchain contains a list of peer nodes, as well as instructions to rendezvous cloud. The rendezvous cloud helps bootstrap the connections between the peer nodes within each private network.

Please get familiar with the core concepts before continue.

0. Workflow Diagram & Roles

ĐNetwork provides tools to define the overlay network, add/delete member nodes and register overlay cloud nodes in DNetDB. The self-contained overlay meta data not only has a list of the member nodes' Crypto ID (PubKey，a.k.a C2PKH), but also the directive about how the nodes can find and connect with each other. As shown on the following diagram, there are seven steps to create an overlay network and performed by three different user roles (Admin, Resource Provider, End User).

Workflow

This section is conceptual, the actual CLIs and App walk-through will be in Quick Start section.

1. Add a dnet record

A DNET record is created in ĐNetDB by DNET_OWNER, ĐNet_Name and ĐNet_ID are created. DNET_OWNER locks the DNET_ID with its public key in the output part of the transaction log so that only the DNET_OWNER can perform the subsequent CRUD operations, like add node to this dnet.

Learn more about ĐNetDB dnet record

2. Add ovc/ovr (ovx) records

An OVX (OVC & OVR) record is created in ĐNetDB by OVX_OWNER, OVX_Name and OVX_ID are created. The owner locks the IDs respectively with its public key in the output part of the transaction log so that only the OVX_OWNER can perform the following DNet authorization step.

The underlying process is similar to creating DNet.

Learn more about ĐNetDB ovc record

3. Add ovc/ovr to dnet

  • OVC --> DNet: OVC is usually a public cloud backend, however private OVC can be easily setup. Public OVC is listed here.

  • OVR --> DNet: since relaying traffic could consume significant bandwidth, OVR is usually a paid cloud subscription service for each individual dnet. The OVR_ID can be obtained from resource providers.

4. Authorize dnet in ovc

DNet --> OVR: Each DNet must have an OVR. The DNET_OWNER share the DNet_ID with the OVR_OWNER. The OVR_OWN adds the DNet_ID along with its signature to its authorized list after receiving payment from DNET_OWNER.

DNet --> OVC: Each DNet must have an OVC. The DNET_OWNER share the DNet_ID with the OVC_OWNER. The OVC_OWN adds the DNet_ID along with its signature to its authorized list. Usually, the OVC resources are public and free. Private OVC can be easily setup.

5. Add nodes to dnet

DNET_OWNER either assigns a Virtual IPv4 or IPv6 address to the node or use an existing one, DNode_ID is added to the DNET_ID;

To add a node to this private network, the dnet owner creates a pseudo token transaction to send the above dnet base UTXO token, as created in Stap 1, to himself, with the scriptPubKey prefixed with OP_DNET_NODE:

   `OP_DNET_NODE <dnet_id> <virtual_ip> <PubKey>`

6. Node Connect to OVC

The dnet creator shares the DNet_ID with member node's owners. Each member node will accept the invitation to join the dnet and the dnet is added to its local dnet list.

DNode and OVC nodes retrieve the ĐNet meta data from the blockchain, DNode then use OVC’s public IP address to connect to the OVC nodes. All nodes will add the member nodes' PubKey which is the base for subsequent encrypted communication.

Upto now, all nodes have peer nodes' PubKey and all are connected with OVC, which is this dnet's cloud backend. The node's PubKey serves both as ID and traffic encryption key. The dnet member nodes have all necessary informations to find each other and ready to connect.

7. Private Overlay Network

OVC nodes implement the protocols to help DNodes to connect to peer DNodes within the same dnet and create virtual path in-between. The protocols are application specific. Existing applications can be ported to run on ĐNet platform. The porting involves two major efforts:

  • The application lifecycle management like init, start, stop and application events management;
  • Mapping the on-chain block data, like node's PubKey and virtual IP address, to the application's configuration setting.

Taking porting a Peer VPN application Tinc-VPN to run on D.Network as example. The Tinc configuration variable

   `ConnectTo = <name>`

can be mapped to the OVC's public IP address, which is available on public blockchain.

The OVC instantiates the abstract dnet definition and implements the protocols for nodes to work together. The next section walks through an example.

What's Next?

The Quick Start section shows the complete steps to deploy and run a slightly modified Tinc VPN on D.Network platform. The Run App on DNet section explain the details and the Port App to DNet gives the details to port an App to DNet platform.

Edit this page on GitHub

On this page