The basic idea is that the public data on blockchain contains a list of peer nodes, as well as instructions to
rendezvous
place for all nodes to 'meet'.
Đ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), but also the directive about how the nodes can find each other and work together. As shown on the following diagram, there are seven steps to create an overlay network and performed by three different roles:
Three types of roles also shown on the diagram:
dnetcoin-cli
commands to manage the dnet records, e.g creating a new dnet and add/delete member nodes, assigning ovc resources;dnetcoin-cli
commands to register ovc cloud resources into DNetDB and app-cli
commands to add authorized dnet.app-cli
commands to initialize, start, join and connect an overlay network.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
An OVC record is created in ĐNetDB by OVC_OWNER, OVC_Name and OVC_ID are created. OVC_OWNER locks the OVC_ID with its public key in the output part of the transaction log so that only the OVC_OWNER can perform the following DNet authroization step.
The underlying process is similar to createing DNet.
Learn more about ĐNetDB ovc record
OVC --> DNet: OVC is usually a paid cloud subscription service for each individual dnet.
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 after receiving payment from DNET_OWNER.
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:
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 block.
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.