Request For Complaints #1
(redirected from 9.PNS)
Inter9 Engineering Task Force
File Name System (FNS)
FNS is designed to replace the centralized domain name system with an alternative that can easily be federated and defederated.
The namespace is divided by the delimeter / like pathnames in a filesystem:
FNS path | DNS equivalent ====================+=================== /shelltalk/jrmu/www | www.jrmu.shelltalk /cloud9p/mkf/mail | mail.mkf.cloud9p /com/google/www | www.google.com
Each FNS server keeps track of its own entries (files and subdirectories) as well as a pointer to its parent, .. in a relative path system. It is analogous to how the UNIX filesystem works, where each inode contains listing of its own files/subdirectories and its parent ..
In the above example, /cloud9p/mkf/mail, / root handles the records for cloud9p; cloud9p handles the record for mkf; and mkf handles the record for mail. FNS queries are distributed in the same way that traditional DNS queries are handled.
What makes FNS unique is that there is no concept of an absolute root, and there are no hard-coded root servers. Instead, to find root, clients must query the parent node .. recursively, until .. points to itself.
By definition, a root node is one where the .. entry points to itself. Because there are no official roots, there can and will exist multiple roots. Any node can declare itself a root simply by pointing its .. entry to itself. The lookup to root always involves recursively querying .. until the root is reached.
Pathnames are all relative and can be moved at any time moved to a new location in the hierarchy, or even a new root. To change the position in the FNS hierarchy, simply change the .. pointer to a new address. This ease of changing parent directories is designed to make it easy to switch FNS root nodes.
Because of the absence of hard-coded root servers, there are no absolute paths, and any given FNS node only keeps track of its children and immediate parent.
Each FNS server chooses where it wants to join the hierarchy, namely, which / root it wants to belong to. It is possible to defederate from this / root and choose a new / root (a chroot FNS split).
In general, users will prefer to have fewer / roots in order to prevent confusion, for simplicity and ease of use. However, because pathnames are relative, it is possible and relatively easy for FNS nameservers to fork. A node simply needs to declare itself as root by setting the .. pointer to itself; and persuade other nodes to set their ... pointer to the new root. This forking mechanism allows forks to take a large chunk of the namespace with them, to deter an abuse of power from / root.
Even though there are multiple roots, it is possible for one root to refer to another.
For example, consider the scenario where ircnow and ircnever both run their own separate, independent FNS roots. Suppose a user is connected to shelltalk, a subdirectory of the ircnow network. He would still be able to lookup and resolve the name turtlespeak on the ircnever namespace:
/shelltalk/../ircnever/turtlespeak
The shelltalk user would first query .. to get to ircnow's / root, then query ircnow's / root to get the address for ircnever, then query ircnever to get the address for turtlespeak.
Although the two nodes, ircnow and ircnever, are independent roots, they can refer to each other as children inodes with pointers, making it possible to connect to independent networks.
In the event of conflicts between networks, ircnever may choose to "sanction" ircnow by removing its directory listing, and ircnow may likewise remove ircnever's directory listing. The users within each respective network can still resolve FNS entries within their own network, but can no longer resolve on enemy networks. Resolving disputes can result in the restoration of broken links.