The public data on blockchain contains a list of peer nodes, as well as instructions to
rendezvouscloud. The rendezvous cloud helps bootstrap the connections between the peer nodes within each private network.
Please get familiar with the core concepts before continue.
Đ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).
This section is conceptual, the actual CLIs and App walk-through will be in Quick Start section.
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.
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.
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.
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.
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>`
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.
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:
`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.
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.