Decentralized services
Last updated
Last updated
Rings Network enables users to integrate services into its decentralized network. Its underlying mechanism relies on Rings DHT for service registration and discovery. Setting up hidden services is a straightforward process that decentralizes any service with just a few simple steps.
For classic Internet architecture, "services" typically refer to centralized services and entities. However, by using a Rings network, it is possible to effectively transform those centralized services into decentralized services.
This is achieved through a Rings custom backend. By configuring the Rings network to act as a transparent forwarder, all messages directed towards a registered service will ultimately be processed by this custom backend handler.
Every de-service provider can register itself in the network. The Rings network will create a key-value pair for each service in the form of hash(services_name): [services_provider_did] and store it using the DHT (Distributed Hash Table) feature across the network. When other network nodes request a de-service, this traffic will be forwarded to the corresponding active node providing that service.
In fact, we will utilize the Chord algorithm to find the corresponding data based on the hash of the register_name. For more details, you can continue reading the section about the Distributed Hash Table (DHT).
De-services can declare themselves as "alive" by using polling. This will help them maintain a relatively higher position in the de-service provider list. When a requester needs to request a de-service, it should first use the "service lookup" command to find the nodes that provide the required service:
This command can also be accomplished through the JSON-RPC API.
It will return a provider list of de-service, and then you can use the elements in the list to request de-services.
Rings CLI provides a set of tools to assist in requesting de-services. This can be accomplished through the command line or via our Curl API.
For command-line usage:
For curl (JSON-RPC) usage
Backends can be classified into various types based on different transmission protocols, such as TCP-Backend, HTTP-Backend, and WASM-Backend. The essence of a backend is that it acts as a custom message handler. It must have a service name and a delegated service path.
For example, we can declare a backend service with the name "ipfs_provider." This service will redirect all requests directed towards its name to a configured prefix handler, which, in our example, is http://127.0.0.1:8080.
Thus, our config.yaml can be looks like this:
Rings allows users to configure hidden services through the "config.yaml" file. If you are not familiar with what "config.yaml" is, I recommend reading up on it.
For a hidden service, three fields need to be provided: "name," "register_service," and "prefix". For example:
This config will perform two tasks:
It will use the "register_service" function to register itself as an "ipfs_provider" within the Rings Network.
It will forward all incoming traffic from the Rings Network to the specified "prefix."
Now let's integrate it into the config.yaml file:
Once all the configurations are set up, you can use the command rings run to start hosting your decentralized services.
