Kueea System is composed of Kueea Networks.
A Kueea Network is a computer network, in which every node is a Kueea Node - one that supports the required set of network services by implementation of corresponding Kueea Modules.
Modules and M-Builds
A Kueea Module is a set of symbols - various kinds of functions and data objects.
An M-Build is an implementation of one or more modules. They are program images interpreted and executed by system software. The system is not dependent on any particular image format, although there exists a preferred format for these images.
Modules are generally published as technical documents, with the goal of standarizing some specific system functionality. The documents specify all symbols in detail and contain, or reference, information necessary for the reader to understand the definitiions.
Modules are identified by their unique identifier and revision number. Revision numbers are incremental. Higher revisions of a module may only add new symbols to the module. Existing symbols are never redefined. Modules are always backward-compatible with lower revisions.
Published modules ought to follow the KISS (Keep It Simple, Stupid) rule. They must be narrow in scope so that their developement ends one day, the module becomes finalized and is never revised again. If it does not need revision, it means it’s good and can be safely used.
__Modules that are constantly revised are broken by design. Such modules ought to be scrapped, made obsolete, and then redesigned as new modules with a new identifier.__
Some modules are published and standarized for the general public. Other modules may be known only to select few or be created as part of module development and have the lifetime of only few hours.
Programs and memory
Kueea System programs are executed by an abstract computer. The processors of the computer do not matter; they are undefined. What matters, however, is the memory that the processors access.
The abstract computer does not exist as one machine. It is implemented as a Kueea Network. Memory of all nodes is the memory of this big computer. The amount of its logical processors depends on its nodes.
There are three distinct memory spaces within Kueea System.
System memory is made of octets, each having a 192-bit address. The higher 128 bits of the address contain a Kueea-Node identifier. The lower 64 bits reference an octet stored by that node. (Note that one machine may function as more than one node.)
Reference to this memory is called a handle. Handles are universally unique, global memory addresses.
Once allocated, data in system memory never changes its address. The address range may be reused only when the object has been destructed.
At one point, the authors considered hardware that could reference the system memory directly, but that idea was abandonded. The problem lies in that if the memory was physically at another node, fetch operation would complete after the data arrives over the network link. The CPU would not be able to execute the next instruction or be interrupted. This would introduce very long delays, which is unacceptable. Long-distance network links also introduce a bunch of other problems. The 192-bit system memory is thus entirely implemented as software.
System tasks are executed by a node's central processing unit. The CPU accesses memory through its virtual memory space. The space is made of bytes, which must be at least 8-bit long. All bits above the lowest 8 are undefined and must be cleared.
The bytes are referenced by 64-bit virtual addresses. These addresses are unique within a given task. In theory, they are translated into system memory addresses.
Current (as of 2019) CPUs reference memory with 64-bit words, of which not even all of the 64 bits are used for the address. The authors believe 264 octets is enough for any task.
Actual data resides at a node's physical memory, i.e. the memory space where actual real devices are mapped to.
In practise, virtual addresses are translated by a CPU into these directly. If the referenced memory is not part of the physical memory of the node, the reference is intercepted and dereferenced by the kernel.
Objects and memory management
Kueea System is an object-oriented system. All allocated memory always contain data of some object.
An object has the following traits:
- location of its data (handle and physical address),
- length of the data (in octets),
- type of the object (class),
- other attributes and flags.
Objects belong to one or more of three memory contexts:
- system context, accessible only to the kernel of a node;
- module context, accessible to all tasks of a given module; and
- task context, accessible only to a particular task.
Function symbols are divided into three types:
- static functions, which access their arguments only and can be executed under any context;
- module functions, which require access to objects in their module’s context; and
- kernel functions, which may only be called by and extend the kernel.
The lifetime of an object is as follows:
- A task requests the system to allocate memory for an object.
- The task gains access to the object’s memory.
- The task invokes the object’s preconstructor; i.e. initializes the object to a safe state. (Precostructors never fail.)
- The task invokes the object’s constructor. If the constructor fails, skip to 7.
- The object is now created.
- Tasks utilze the object.
- Tasks lose access to the object.
- When there are no more tasks with access to the object, the system invokes the object’s destructor.
- The system deallocates the object’s memory.
This poses a question: What should the system do when a destructor fails? The preferred answer of the authors is to log the event and continue.
Classes and interfaces
Every object is an instance of some class. Classes contain data and function members. Function members are often called methods of the class.
Classes may implement sets of members called interfaces. If the member is a data member, the class must contain this object somewhere within its data structure.
Information about classes and their interfaces is stored within special read-only objects called class descriptors.
Tasks may access this descriptor, which allows a task to execute interface functions without any prior knowledge about a given object. Programs are written to either manipulate an object based its type, or based on the object’s implemented set of interfaces.
In other words, run-time type information about objects is a part of the system’s ABI in order to provide system-wide virtual function functionality to every task in the system, regardless of the language a program has been written in.
Tasks have no predefined starting point. They begin at any function and end when that function returns.
Tasks may call functions in separate, distinct tasks. The caller task becomes the task owner of the callee.
These ownership relations form a hierarchical tree structure. When a task is taken out of the tree, it becomes a detached task.
Task ownership may be transferred to another task, as long as the target task is located deeper (in the tree) than the current owner and the caller. Detached tasks are an exception - any task may become their owner.
Tasks and objects
The system assumes objects are big and complex data structures. Copies of objects are never created by the kernel. All memory (except the stack) is shareable between tasks. The kernel’s main job is controlling access to object data.
The core functionality of Kueea System is tasks’ ability to gain direct access to objects created by other tasks. This operation also gives access to any referenced subobjects.
At beginning, a task gains access to its primary function’s arguments. If it is a module function, the task also inherits the module context.
When a task calls a module function within its own context, the module context is changed before the call and restored while returning.
Tasks may return a value, which their owner can later obtain. Values returned by detached tasks are forgotten immediately.
The term peer or node refer to a machine that is connected to other machines with some kind of network technology. Ethernet and Internet are examples of such technology. Kueea Network is yet another network layer.
Generally, in Kueea System documents, nodes refer to a single thing, whereas peers are used in the context of a connection.
Topology of Kueea Networks is a peer-to-peer mesh, although this network may be composed of only one node.
Each Kueea Network is defined by its trust anchor. It is a set of entities whose statements every node must trust. A node becomes part of a network by trusting its anchor. In other words, all nodes of a network commonly trust some set of entities. It is this trust that defines the network.
One node may be a peer in multiple Kueea Networks at the same time. Which network is to be considered is based on who sent a message.
The goal of Kueea System is a state where every node on the Internet agrees on a common trust anchor, i.e. every node on the Internet is part of one big Kueea Network. Realistically, this will probably never happen.
Resources in Kueea System are all vertices of a global graph. Resources are always referenced directly by their identifier(s), although said identifier(s) may have hierarchical components.
Resources are either device-independent, in which case their identifiers are node-agnostic and do not take device or node identifiers into account; or they are device-specific, in which case the node needs to be specified.
Device-specific resources are generally limited to physical devices only.
Data resources are usually referenced by describing their content, so that the data can freely change its physical network location. It ought to be located physically closer to where it is needed. The system’s job is to automatically take care of this. Another is to monitor its nodes, the amount of copies and managing the data so that as many of valuable resources as possible are preserved.
Kueea and user sessions
Resources called kueea are entities on behalf of which tasks are executed. Kueea do not necessarily represent living beings. Think of it as a mask a human puts on when interacting with others.
User resources are collections of private kueea data. When someone wants to use the system, the person points the system to its user resource. The user resource should be stored on a device one carries with oneself. It could be a pendrive or some other removable storage device. The data should never be stored on a publicly accessible storage medium.
Once the system has access to the user resource, it asks the user to provide information required to access kueea credentials stored in the user resource. When the data is successfully accessed, the system requests the user to provide a system shell and select the default kueea for the session.
Shells are designed so that users may freely switch between their kueea within the same user session.
Kueea are globally unique resources, generated independently of the system and then registered with a Kueea Network in order to be recognized. Users themselves are the sole authoritative source of information about their kueea, although there is a third-party trust anchor involved. The trust anchor verifies the method of authenticating a kueea.
Authentication is generally based on asymmetric cryptography, in which case the trust anchor is needed to certifiy the kueea’s public key.
Policy and access control
Access control in Kueea System is consensus-based. It is determined by a network’s network policy. A node determines whether a kueea has access to a resource based on information coming from the network it is a part of. This policy is certified by the network’s trust anchor.
Data resources always have a public metadata document. This metadata contains access control information among other things. It is always transferred before the data proper, which might be protected.
If resource data is unavalable, the node will look for it on the network. In order to successfully fetch it, the other peer must also agree on the assessment that the kueea in question has the required rights.
Peers that requests data on behalf of kueea that do not have rights to said data are mailicious and are to be banned by every node in a network. Malicious peers are eliminated by denying them access to other peers. The policy is data for the system, which is automatically executed.
The punishment here is that the peer becomes alone, without access to any of the resources offered by the network. If it wishes to regain access to the resources, it must follow the policy. An important part here is that the policy is publicly available for review and that the peer must be informed of any ban’s reason. If the peer does not agree with the rules in the policy, the options left are to establish a new network or look for another. Discussing a policy can only be done while within a network.
If a peer does not follow the agreed-on policy in its network, it effectively creates another, hidden network. In order to become part of this hidden network, one would need to somehow obtain addresses of its hidden peers. All peers would also have to trust each other in order to stay hidden. In other words, it is very difficult for such networks to gain peers.