DDC | dCDN Node

About DDC | dCDN Node

Picture the CDN Node as the vigilant courier of the digital realm—a steadfast facilitator ensuring the swift and seamless journey of videos, images, and content, holding a mirror of frequently accessed local content, ushering in speed and fluidity. Cere's pioneering dCDN nodes form the backbone of this performance, orchestrating a frictionless global odyssey for the Decentralized Data cloud. What distinguishes our dCDN network from its conventional counterparts is its multi-clustered assemblage of lightweight content delivery nodes, adorned with intricate layers of caching prowess. Here's where it gets exciting: You too can partake in this revolution. Set forth your own beacon of content delivery by igniting your own decentralized CDN Node, amplifying the Cere Network's might. By joining hands, you sculpt the future of expeditious content access for your digital compatriots.

Github Repository: ddc-cdn-node (opening soon)

DDC | dCDN Tech Stack

Architecture diagram

Each DDC CDN Node is an isolated piece of software that can join to the network with other nodes.

It highly utilises internal memory (RAM) and physical storage for 2 cache levels. Each Storage Node is connected to Cere Blockchain, listens for the changes in cluster topology and reacts to it by updating caches, access policy or network topology.

DDC Storage Node provides HTTP API with operations to store, lookup and retrieve the pieces of data.

Geo Routing

Solutions:

Geo Routing helps route client traffic to the closest DDC CDN node.

Initially, a centralized approach to Geo Routing will be used while a decentralized solution is worked on as a replacement in parallel.

Points of discussion remain

CDN nodes already have an embedded database with O(1) access complexity to the content. To optimize read/write efficiency, dCDN will use an in memory database.

Using an in memory key/value store is a great way to build highly performant applications. There’re two approaches to implement:

For the first phase of dCDN development, we have decided to go with Embedded in-memory caching, implemented in Golang, that meets our internal requirements for the following properties.

Before adding content to cache - `gzip` compression will be used to reduce the content's byte-size. End-user devices must decompress on read.

CDN should have 2 levels of cache.

  • The first level is an in-memory cache with the most popular chunks served from this node.
  • The second level is a key-value DB with links to the recently requested data chunks from storage nodes.

Database Caching

CDN nodes already have an embedded database with O(1) access complexity to the content. To optimize read/write efficiency, dCDN will use an in memory database.

General (In-Memory) Caching

Using an in memory key/value store is a great way to build highly performant applications.

There’re two approaches to implement:

  • Cache-aside (eg, Redis)
  • Embedded in-memory

For the first phase of dCDN development, we have decided to go with Embedded in-memory caching, implemented in Golang, that meets our internal requirements for the following properties.

  • High concurrency
  • Data structure
  • Capacity
  • TTL
  • Statistics

Compressing of objects

Before adding content to cache - gzip compression will be used to reduce the content's byte-size. End-user devices must decompress on read.

Cache Metrics

dCDN operations must be measured precisely and verifiably in order to account for required payment for services provided. Metrics will also be tracked to provide the required information about the current node cache state in runtime. The details of metrics tracked by the dCDN nodes and implementation details are still in development. More information coming soon.

DDC | DDC dCDN Tech Stack Use Cases