The nodal model
 |
|
Introduction
A nodal network is formed from many peers each running the nodal reduction algorithm. Nodal reduction operates on the local node space which is a collection of nodes on top of a list space.
- Node
A node is like a hash table or associative array. Another way of looking at a node is as a file folder. Internally, nodes are referred to by GUIDs or node references, which are meaningful only by their distinction from each other. In the user interface nodes are referred to by names appropriate to the context in which they're being referred to. GUID's are used for referring to nodes persistently for storage and communications, but direct implementation-specific memory references are used at runtime.
Like a hash table, nodes are containers of keys and values, but because all runtime node referencing is direct, the keys and values are references, not textual names like usual.
- Nodal Network
The Nodal Network is formed from communications between all the Peers. Each Peer applies the Nodal Reduction process to its local Nodal Space, resulting in the organisation of globally unique nodes identities and the propagation of change throughout the network.
Storage and distribution is a nodal organisation which extends reduction out to form a single harmonic global reduction space called the nodal network.
Large organisations involving the process and resources of many individual nodal peers rotate on larger loop cycles which are the globally known harmonics of spectrum.
- DHT-like
- Routing & Discovery methods
- Execution
- Function bindings and references
- Nodes have a common method of describing the sequence and scheduling of processes
- Reduction
- Event model & schedule
- Persistence
- Serialise & Deserialise
- Serialise builds a textual representation of a nodes structure, this is not an atomic process
- Interface & Content
- Renderable structure, including interface event represntation
- Applicational content
old intro text
Why do we need to start at such a basic level, when powerful high-level data-structures already exist in most programming environments that can easily support this? because:
- Wikipedia:Mutex
- Wikipedia:Linearizability
- Wikipedia:Non-blocking synchronization
- Wikipedia:Lock-free and wait-free algorithms (a fragment extracted follows)
- Writing a program that uses lock-free data structures is not a simple matter of merely rewriting the algorithms you would normally protect with a mutex to be lock-free. Because lock-free algorithms are so difficult to write, researchers focus on writing lock-free versions of basic data structures such as stacks, queues, sets, and hash tables. These allow programs to easily exchange data between threads asynchronously.
- For example, consider a banking program where each thread represents a virtual teller. A lock-based approach to making a deposit could be to have one teller lock an account to make a deposit, so that two tellers don't try to deposit into the same account simultaneously. To make the process lock-free, rather than designing a lock-free "deposit" algorithm you might have the teller submit a "deposit" request asynchronously to a centralized thread that handled all deposits.
Each different programming language has it's own strengths and weaknesses across many different contexts such as efficiency, portability, scalability, availability of programmers, application-vendor support, protocol/standards support etc. But one area which is common to all languages and benefits greatly from unification is the concept of program-flow.
The concept of program-flow itself comes in many flavours which appear in all combinations across the different programming environments. Some of these program-flow concepts are subroutines, conditional-structures, looping structures, event models and multi-threading models.
The nodal model can completely replace the program-flow aspects of the environments with a unified organisational environment in which the functions and objects of other languages are managed and executed to a schedule.
The nodal model does not use methods as such, but rather is more of a code-snipit model allowing larger code-fragments to be made from executing threads of snipits. Snipits are organised by language and environment bindings.
This organisational environment is recursive and can therefore not only form applications from the organisation of function-execution, but also forms real-world organisations by integrating the same organisational environment with our own goals, roles, and resources.
- Moment: A moment is purely instance. Each node exhibits a loop which passes through the current-focus of all the currently active threads in the context. In fact the only way a thread can ever execute is by being inserted into the active-loop of its parent.
- P2P and change propagation. Editing conflicts are made more of a problem in P2P due to the slow update. In a Nodal environment, editing conflicts are practically non-existent, and are easily resolved if they do occur. This is because the difficulty of the conflict is related to the size of the "atoms" involved (the smallest indivisible units undergoing change). In the case of current Wiki, CVS and most collaborative document systems is that these atoms are entire articles or files.
- See Also
- Nodal structure overview
In this project the network nodes are not files, but objects. The whole network can be considered as one giant structure of persistent objects. In such an environment, there can be no static-inheritence-structure to compliment the runtime-object-structure as in most programming environments, because runtime is all there is! So a prototype-based object-paradigm like that used by ECMA Script has been adopted, where objects are "sub-classed" from other objects "in the field".
The terms class and instance can still apply, but in a prototype-based environment these terms represent relative relationships between nodes, rather than absolute information about a node.... old text regarding axes was removed from here --Nad 15:16, 20 Aug 2006 (NZST) the class and instance division of content is associations and current-loop, see Node.
A major difference between working with prototypes rather than classes is that a class is completely static, it determines the types and names of all the methods and properties its instances will have throughout their entire lives. A prototype however, simply defines the contents of an object at the time of its instantiation. But this initial content is not fixed, the set of available methods and properties changes with the time in the same way as a person performs different roles throughout time.
Another issue worth mentioning here is that we are using Multiple Inheritance which has been a sensitive issue in programming for many years. Most of the problems with multiple inheritance are ultimately due to naming conflicts, which are irrelevent concerns in this model since nodes are referred to by their unique identifiers, not by their often ambiguous names.
Each node is like an associative array containing an arbitrary number of "named" references to other nodes. Of course the names are not ASCII as in normal associative arrays or objects, but Node references. parent-child-axis stuff was removed from here. Parent-child (instance axis) is the tree of nodes formed by the current-loops which undergo reduction (the now), the class axis is the tree of all associations. --Nad 15:21, 20 Aug 2006 (NZST)
- Applicable concepts
Here's a list of concepts from Wikipedia which all apply to this model helping to describe what it is. The peer software...
- is a Distributed Object Space (a.k.a Tuple Space)
- is a Prototype-based programming environment
- is an Aspect-oriented programming environment
- is a Metaprogramming environment
- is an Intentional Programming environment
- is an Integrated development environment
- has Reflection
- is a Dynamic programming language
- is an Internet Operating System
- List Space
The next level of the system is List Space. It is this layer which is used by nodes in Node-Space to undergo change and remember. List-space has only two functions:
- Getting and Setting (get/set(ref,key0/1/2))
- Shifting Position (traverse(ref,ref))
The space above this is Node-Space, which is similar in some ways to the doubly linked circular list (or loop) data structure (see linked-list), which in turn some advantages and disadvantages over arrays.
List-space offers only an associative ability (associate one thing with another thing). It's only called list space because its made from the same structure as linked lists and can support them all. Functions like reduction or traversing loops or linked lists ore actually done in Node-Space, which too uses associations, not list-item-keys like a linked list would.
NOTE: Actually there is one doubly-linked-list in list-space which is all the unused list-items. Get and Set also perform creation (by getting non-existent locations) and deletion (setting existing ones to root/zero/null), and this creation/deletion process involves unlinking and relinking items from the free-list. On initialisation of list-space all items form one long doubly linked list.
Traversal: (a.k.a binary-traversal, list-space-traversal)
- relative associations from interpreting binary-ref as key direction instructions
I was thinking that a good foundation for a lot of other discussion is the concept of binary in general. Binary is the simplest form of distinction, and the bit is the most fundamental unit of information. Binary and is not only made of two states, or symbols, but also gives rise to two different ways when considering sets of bits. These two basic ways are the root of the two domains.
- Names: The using of the binary sequence simply as being distinct from all other sequences. In the nodal model, traversal is used to assign distinct sequences to a particular piece of information.
- Number: A simple geometric which compliments traversal gives rise to ordered sequence, and using recursion is infinetly divisable. Ie a discrete process which forms a continuum. In the nodal model, the geometry is based on this method - recursively dividing a window or period.
- Node Space
- Nodes & Associations
All of Node-space's functionality and structure is built from the associative-array-like functionality provided by list-space's binary traversal mechanism. Node-spaces fundamental data-structure is the loop, a kind of linked-list, but the links referred to are not list-item-references, but associations,as defined by list-space-traversal.
- here's some greek notes from the code comments regarding nodal structure:
- an association is a typed-relationship between its container and another node
- So there are three nodes involved here, the container, the other and the type
- each node contains only associations - it is a set of class:instance associations
- I've used the word set instead of list here, because its by traversal that you get to them, there's no full list of them
- Although class:instance associations are analageous to key:value pairs in associative-arrays, they are not name-based, and you can't iterate through a list of them all
- In each node, there are four fundamental associations, prev/next and parent/current
- prev/next and parent/current (they can be called axes, horizontal and vertical)
- These four are common to all because they are the concepts used by reduction which defines the fundamental functionality of node-space.
- The prev/next associations form loops, and all the nodes in a loop are called siblings.
- The loops contain a subset of the nodes associations, and can be iterated through because they're linked lists
- All the associations within a node are its 'potential content/structure, and those in the loop are actual
- Nodal methods are create/delete/get/set association, and reduction
- Data-structure Loop
Each item in this linked-list is made of three item-references: a reference to the Previous item, the content itself (the "Middle"), and a reference to the Next item.
- best to intro linked lists here really and in terms of nodes since not used in this way in list-space
this is node space and forms doubly-linked-circular lists (loops) from next/prev associations (not list-space-keys)
Unlike standard loopsdoubly-linked-lists, every list-item in a loop is indistinct (apart from the current contents of its middle list-item-reference). Any item in the loop can serve as the current-access-point,i.e. a reference to a loop may change between different items in the loop throughout time.
This allows us to establish cycles, knowing where the current-access-points are going to be in the future allows a harmonicallly based data system based on cycles that may not yet be complete. This makes more common sense than most systems, being more like natural objects.
- In standard linked-list terms a loop is a doubly-linked-circular-list
- Nodal Reduction
If each middle-key points to somewhere in another loop, we can see this loop as a torus (a tree of loops), or doughnut-shape, and each of the middle nodes can be a torus itself, so it is recursive, although at this basic level that isn't relevant.
Operating from the level above upon this list-arrangement in List-Space, is the generic process of reduction occuring in Node-Space, where after an operation is performed within a list-item, the torus shifts on its axis like a stepper motor and is ready to perform an operation on the next list-item.
Rotation and reduction are in the nodal-space level which is above list-space, and need know nothing about why what it did just worked.
Similarly, and one level up, an application or interface can manipulate what's in the loop, and therefore what gets executed and in what order and with what proportion of its resource, but the actual process of rotation and reduction is inherent in the data-structure, the application need know nothing about this level.
For a discussion on where this lowest-level process relates to the whole scheme of the project, see Nodal-space vs List-space.
- Some nodal-reduction code notes
- Reduction starts at root, every iteration of reduction involves one quanta being sent to root
- The root-node is also the first list-space item
- root has an actual-loop just like all other nodes which rotates like normal each quanta
- the root is all the high-level information and processes this peer supports or cares about
- Like any other node, root contains potential-content, but in the special case of root, the potential content is every node this peer knows about. Also because its the root context, traversal is not necessary to reach those nodes - the direct reference, or address of the node is itself-within-the-context-of-root.
- Quanta poor in a rotate withinwards as per the dynamic diagram that doesn't exist yet
- When a quantum reaches a node exhibiting a local declaration, it executes it and that iteration of reduction is finished
- As the quanta trickle down, rotation happens at every level regardless of whether or not execution occurred
- Each quanta is really two, one for whole, one for part.
- This is because when execution happens a second quantum is also sent to the class. This way all the non-actual associations in root also get quanta used for managing their many instances "in the field"
- Processing and Data Storage/Access
Each "middle" list-itemThe data structure can process, store and move information at the same time, rather than the more usual two roles (processing - data IO). The data-structure inherently handles both storage and processing. The nodal structure allows peers to use their processing ability as a generic resource.
This can happen because it is a data structure that requires processing to work, all you need to do is to call its reduce function with no parameters.
The reduce function is called to provide a quanta of processing to the system. A quanta may be thought of as the smallest unit of time/energy available to the system. Once the quanta is consumed, processing stops until the next iteration of reduction.
The functions that are executed are a set of core nodal functions that are implemented in all major languages. By analogy, in XML, the DOM allows you to implement the particular tree in runtime that is specified by the XML and offers a number of generic methods designed to analyse and manipulate trees of DOM form, i.e. you can match patterns in the tree and you can manipulate the structure directly.
The improvement we can see over the DOM object concept is not only in the efficiency of the process, but also that the notion of time is incorporated into the processing/data IO paradigm of the project, since the data undergoes change based on its structure. The programming, therefore, is replaced by collections of data that undergo change automatically due to their structure.
The efficiencies occur because the structure is inherently thin, i.e. the methods used are few and simple, as opposed to the myriad of complex methods need to manipulate DOM objects. This is because the conceptual structure of XML is far more complex than that of the project.
Resolve: (was called path-traversal, nodal-traversal)
- Accepts a path-list of nodes and traverses each in series to arrive at a final target
- Peer-Space
- Harmonic Organisation
- GUID's
- Storage & Distribution
- Sessions (moments)
- To Add
// instance.create/delete(class) calls class.create/delete(instance) // create inserts the instance into the classes instance-loop (list-aspect, next/prev) // ie. our list of current children (that our E divides amongst) is also our instance-loop // has or is are one, they're all just relationships that receive a portion of energy // laster: a chain of delegate classes is created between root and the instance // - the class of any assoc requires a portion of the quanta // remember, next/prev and complimented by parent/current (parent is also class) // - this allows alternate quanta be divided between parent and current, thus providing // energy for the class->instance relationship // - get retreives from class value if no instance value at each step of a path
// - all instance-loops work by going cd this.current then assigning this.current.next to it
// when a function executes, it can update the loop at that location (equiv to array.push)
// - a functions parameters (and even further methods and tools) are child associations
// the structures necessary to build the fucntion are child assocs too
- Threads: conversation, list of instructions, phases or cycles of operation. These phases can also loop in a cycle like seasons or days of the week. The items that make up these lists are in general called Moments. Threads are not instances, they can only exist conceptually. There can never be any such thing as an actual thread because only one part of it can exist "in the Now". It's because the thread-nature of it stretches along the dimension of time.
- Moments: A moment is purely instance. Each node exhibits a loop which passes through the current-focus of all the currently active threads in the context. In fact the only way a thread can ever execute is by being inserted into the active-loop of its parent.
- P2P and change propagation. Editing conflicts are made more of a problem in P2P due to the slow update. In a Nodal environment, editing conflicts are practically non-existent, and are easily resolved if they do occur. This is because the difficulty of the conflict is related to the size of the "atoms" involved (the smallest indivisible units undergoing change). In the case of current Wiki, CVS and most collaborative document systems is that these atoms are entire articles or files.
- See also Diff
- Schedule
The schedule is used at all layers; process execution, application, people and organisations. Here we discuss it in terms of the concepts and processes which make it up.
- Entropy & Potential
- Auto reduction
- Resource
The nodal version of the storage concept is actually Resource; the general idea of allocating, or "booking" the use of any kinds of resources to a schedule.
| 
|
