NTK_RFC 0009
Subject: Scattered Name Service Disgregation
This text describes the Scattered Name Service Disgregation, an extension of the ANDNA protocol. It will be included in the final documentation, so feel free to correct it. But if you want to change the system here described, please contact us first.
SNSD
The Scattered Name Service Disgregation is the generalization of the DNS MX concept. With the SNSD a hostname can be associated to multiple IPs. Each assigned IP has a service number, in this way the IPs with the same service number are grouped in an array. In the resolution request the client will specify the service number too, therefore it will get the IP associated to the hostname which has the specified service number. Example:
The node X has registered the hostname "angelica". The default IP of "angelica" is 1.2.3.4. X associates the 11.22.33.44 IP to the `http' service number (80) too.
When the node Y resolves normally "angelica", it gets 1.2.3.4, but when its web browser tries to resolve it, it asks for the IP associated to the `http' service, therefore the resolution will return 11.22.33.44.
The node which has the 11.22.33.44 IP is called "SNSD node". The IP of the SNSD node is called "SNSD IP". The node which has the 1.2.3.4 IP is always called "register node", but can also be name "Zero SNSD node".
Note that with the SNSD, the NTK_RFC 0004 will be completely deprecated.
Service and priority number
Service number
The service number specifies the scope of an IP. The IP associated to the service number `x' will be returned only to a resolution request which has the same service number.
A service number is the port number of a specific service. The port of the service can be retrieved from /etc/services.
An IP of service number 0 corresponds to a normal IP. It will be returned to a general resolution request.
Priority
The IP has also a priority number. This number specifies the priority of the IP inside its service array. This is how a hash_node chooses which IP will be replied to a resolution request:
First of all it goes in the array of the specified service number. Let's suppose that in the `http' service number array there are 8 different IPs. The IP, which will be sent in the reply, is chosen in a pseudo-random manner: each IP has a probability to be picked, which is proportional to its priority number, therefore the IPs with the higher priority are more likely to be picked. If the IPs have the same priority, then the choice is completely random.
SNSD Registration
The registration method of a SNSD IP is similar to that described in the NTK_RFC 0004.
The SNSD node has to take care of the registration and the updating of its IP. It will send normal registration requests to ANDNA, but it will sign the request with the same privke of the register_node. In the registration request the relative service and priority number will be specified too. The hash_node which receives the registration won't contact the counter_node, because the hostname is already registered and it doesn't need to verify anything about it. It has only to check the validity of the signature, in this way, it is sure that the request was sent by a "friend" of the register_node.
The steps necessary to register a SNSD IP are:
- Copy the ANDNA keyring of the register node, which is saved in its lcl_cache, to the SNSD node:
register_node# cd /usr/share/netsukuku/ register_node# scp andna_lcl_keyring snsd_node:/etc/netsukuku/snsd/<HNAME>[:<service>[:<priority>]] # <HNAME> is the hname of the register_node # <service> is the service number. It is separated from the <HNAME> by a ':' # character. # <priority> is the priority number. It is optional and it is seperated from the <service> # number by a ':' character. To specify the priority number it is also # necessary to specify the service number.
- Send a SIGHUP to the NetsukukuD of the SNSD node:
register_node# ssh snsd_node "killall -SIGHUP ntkd"
related: ["Netsukuku RFC"]