DADI has rebranded to Edge. Find out more.

Introducing the DADI Testnet

Following several months of focused R&D, the last two quarters of 2017 saw us rapidly progress development on the network, taking our testnet to live in October and moving it into production testing.

We’ve been looking forward to writing this update. Not only because it spills detail on the status of our testnet (which up until this point we’ve confirmed only as ‘in development’), but also because we’ll soon be announcing how you can be part of the testing process and experience the network for yourself. But more on that at the end of this article.

First, some context. Following several months of focused R&D, the last two quarters of 2017 saw us rapidly progress development on the network, taking our testnet to live in October and moving it into production testing with a single web service (DADI CDN) in November.

The testnet is currently small - it’s running on our hardware testbed with Netwise in London Bridge, and across a bunch of Raspberry Pi’s connected to routers in our employees’ homes.

Some of the DADI testnet in our employees' homes.

The Raspberry Pi is a low-powered, low-footprint machine, developed with affordability and versatility in mind. These features make it a great low-end benchmark for performance testing the Host component of the network.

But being small doesn’t mean that it lacks punch. The predominantly Pi-powered testnet has handled over 5m requests in the last two months and has maintained 100% uptime.

🔗Network nodes

The testnet is running all three major components of the DADI network: Stargates, Gateways and Hosts. Each has a unique role to play in enabling our decentralized infrastructure, and the current version of each that is deployed to the testnet reflects what we consider to be a minimum working product.

The DADI network.

🔗Stargates

Stargates manage DNS and routing in the network, distributing incoming traffic to the appropriate Gateway, based on their knowledge of which Gateways are handling requests for the corresponding web service.

They also manage the distribution of application data to all Gateways and Hosts, as well as handling the coordination of network devices, allowing the network to ‘talk’. Realtime communication between devices in the network enables the scaling resources on demand.

🔗Gateways

When a request reaches the Gateway, it joins an in-memory queue. Each connected Host plucks a job from the queue, resolves the request and returns the response back via the queue handler to the end user.

🔗Hosts

Each Host is responsible for a single Consumer application within the DADI network (a single tenancy setup that helps to ensure performance). When you deploy to the network, it replicates across Hosts to meet the unique requirements of your web services setup. As with our testnet, a Host can be anything from a rack in a server farm, to a Raspberry Pi wired into a home router.

🔗Network footprint

The testnet currently has a tiny footprint — 20 low powered machines in two countries (the United Kingdom and Portugal).

We will be expanding this rapidly over the coming months, placing nodes with our connectivity partners, predominantly focused on Europe and the United States in the first instance.

The testnet will become a shadow network to the backbone of the mainnet: present in all key locations to provide a complete testing setup for future developments.

Early network footprint.

🔗A peak under the hood

🔗Firewall… what firewall?

Ensuring that Hosts could live anywhere has been a key focus for the engineering team.

The obstacles faced by a server running on a home network traditionally make it very difficult to create a reliable entry point into a networked service. For a start, most ISPs use an IP pool, meaning that your home IP address regularly changes without warning. Even if with a fixed IP, you still need to configure port forwarding on the router, and manually assign a single port per networked machine.

Remote Procedure Calls (RPC) is a protocol that allows for the distribution of procedures across a network of machines. We’ve chosen to make use of GRPC — a universal RPC framework — to distribute traffic from a single Gateway to multiple Hosts within the network. Because GRPC uses standards-based HTTP/2 as transport, it easily traverses proxies and firewalls, enabling it to be setup in a home environment without the need for router/firewall configuration — a key requirement for the Host component in the network.

🔗Distributed configuration coordination

Keeping an eye on resources is an essential requirement for any distributed infrastructure. To manage hardware, the network needs realtime information on current capacity, granular system load information and application integrity.

Apache Zookeeper is an extremely simple, reliable application for handling the distributed synchronisation and coordination of persistent and ephemeral configuration data. Each Stargate in the DADI network Hosts a Zookeeper server, creating persistent configuration directories for Gateways and Hosts to interact.

When Gateways or Hosts connect to a Stargate, they create their own unique ephemeral node. And each node replicates it in appropriate directories according to status, for instance if a Gateway needs more Hosts, it replicates itself into ‘Awaiting Hosts’. Any new or idle Hosts in the network watch this directory for changes and connect to any new candidates that join the directory.

🔗Adding apps into the mix

For the first iteration of the network we decided to deploy apps to DADI Host with Docker. In the next phase we’ll be moving the containers onto an encrypted VMM.

When a Host launches, the Host system app checks for running Docker processes, identifying those that are running DADI services, such as CDN, Web, API and Publish.

The Host polls the Gateway request queue for requests pertaining to the application running on the Host machine.

Pub/sub strcuture.

🔗App distribution

We’re working on methods to handle distributing apps within the network. Each consumer app will have unique system and bandwidth requirements, which should be configurable to allow for growth/contraction over time. Our approach to this remains work in progress.

🔗Want to get involved?

We’re really happy with the performance we’ve achieved so far on the testnet. So happy that we’d like to bring some of the community into the next phase of network testing.

To this end we will opening up applications to be part of the testnet. We will be looking for individuals from around the world to join the network — successful applicants will be provided a low-powered computer with DADI Host preinstalled and capable of running DADI CDN and DADI Web.

We’ll be providing more details regarding the community involvement project in a future post. Keep an eye on our usual social channels — plus the news feed in your account page at dadi.cloud — to be the first to hear about it.

Related articles

More updates articles
Mail icon

Like what you are reading? Want to earn tokens by becoming an Edge Node? Save money on your hosting services? Build amazing digital products on top of Edge services? Join our mailing list.

To hear about our news, events, products and services, subscribe now. You can also indicate which services you are interested in, which we use for research and to inform the content that we send.

* You can unsubscribe at any time by emailing us at data@edge.network or by clicking on the unsubscribe link which can be found in our emails to you. Read our Privacy Policy.
Winner Best Edge Computing Platform Technology & Innovation Awards
Presented by Juniper Research