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)
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 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.
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:
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.
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.
