Communications

Legacy: This article describes a concept that has been superseded in the course of ongoing development on the Organic Design wiki. Please do not develop this any further or base work on this concept, this is only useful for a historic record of work done. You may find a link to the currently used concept or function in this article, if not you can contact the author to find out what has taken the place of this legacy item.

Unification

Unification is one of the main aspects of the project since it is about having a single underlying principle govern the bahviour of many diverse contexts. The Communications nodal organisation is a unification of the processes governing the three most generic informational resources; persistent storage, data processing and network bandwidth. All these have the same processes in common because they're all comsumable resources which require a "bookable" schedule, and the workload of each kind is broken up into packets for processing in the same way.

This unified result can be seen conceptually as an organisation which maintains the concurrent existence of the same information in many separate contexts (each occupying storage resource). Here the term "separate" means that when such information undergoes change, there is a cost in terms of processing and bandwidth resource. This separation means that syncronisation takes time, and the shorter the time, the higher the energy cost. So a global system of harmoncally related cycles (spectrum) is used to allow all contexts to work to a known cycle in their usage and updating of information.

This generic approach allows many other protocols or forms of bookable resource at all scales to be organised in the same way.

Current 2007 plans

The current nodal implementation of this concept is io.c which was developed in 2006 and runs in the peerd.c based peers. io.c currently handles files and TCP/IP streams, but is being restructured to unify all of input/output which currentl covers all kinds of input/output messages from its environment, including keyboard/mouse and time events.

The first step in 2007 for Communications is to get it working in a similar way to the current wikid-based fileSync function but more efficient and robust. It would still use the current wiki as its interface in the same way as fileSync until interface.c is mature enough.

Protocols

The idea is to be able to add new nodes exhibiting functionality for different kinds of caches to be maintained such as filesystem structures, wiki articles, database content, HTML, PDF, email etc. The only differences between them is the sequence of functions needing to be executed within the context of the content whenever changes are detected.

There are many different kinds of attributes or functions which may need to occur to keep different kinds of caches up to date, for example some need to be completely rebuilt when any part changes, whereas others can have only the changed content updated. Each protocol is just a set of specific functions which can transfer these protocol specific states to and from a nodal context. Each item in the rules tree is defining the schedule and the sequences of functions to apply for each destination cache of each source.

Event model

The other aspect of communications is the event-driven aspect, incoming events over various protocols results in the information being hooked into a Down in the nodal reduction loop-tree along with the roles required to process it.

Propagation of change

Each actual period of each cycle is represented by a particular globally known node so that any node can use associations as a common schedule format. Groups of separate nodes need to have common information, but it takes time and energy for changes to any local node space to propagate amongst the others in the group. By knowing the approximate resource requirements required to propagate the changes within any particular context, a suitable cycle can be agreed upon where only the first half of the period is used to propagate changes. The later half of the cycle guaruntees the content to be in a static state which is the same for all in the group.

Transport schedule

[math]\sum_{i = 1}^{n} {i}[/math]

AB AC AD BC BD CD

The schedule of traffic between peers as seen from the global perspective and assuming the simplest situation of all peers needing to communicate with all other peers using the same amount of bandwidth, requires (n2+n)/2 sessions to be booked. A session in this case is meaning the booking a portion of bandwidth for the same period of time on two peers and establishing a bidirectional stream between them for that time.

The central cycle of global activity is the local day/night cycle because that's the dominant cycle determining the timing of information availability. ie that the majority of syncronisation would be occuring at night time.

These total windows of time are divided into static and dynamic slots so that a portion of bandwidth is always available for spontaneous use.

Channels

The content which actually occupies the schedule comes from the applications, starting with the lowest level ones forming the base traffic and schedule within which higher level applications fit. Identity and Security are the low level S&D clients.

All the storage resources managed by S&D can be thought of as channels (like TV channels) where the future content is collaborated on by interested groups or members. This process creates a difference between the current state of the channel and the future state which is the basis of the S&D task queue. S&D uses these differences and the required times of availability at various endpoints of the content to determine what content should be booked for delivery in the transport schedule.

Nodal Structure

The structure of what's contained within what in the loop tree is determined by the order resulting in least context-switches. In the context of S&D this order is

Root → Resources → Types → Instances → Sessions

So all the kinds of resources (Storage, processing, bandwidth, role-hours etc) have a common association structure defined by the root resource node which specify the general methods such as

open close read write create delete

These methods are just abstract nodal interfaces defining the methods and associations necessary to act as a resource, the actual code in them is specific to the environment and the kind of resource so is defined in the instance of resource. The storage resources are therefore used in a uniform way so that

nodeGetValue nodeSetValue nodeInsertKey nodeRemoveKey nodeInsertLoop nodeRemoveLoop nodeGetState nodeSetState

can be described purely nodally in the general resource node and need not be changed in the specific instances.

See also

• Wikipedia:Organizational communication
• Identity
• Nodal Reduction
• io.c - current implementation of storage & distribution in peerd