Communications

From Organic Design wiki
Revision as of 22:51, 10 December 2006 by Nad (talk | contribs)


Cone.png This article or section is a stub. Stubs are articles that have not yet received substantial attention from the authors. They are short or insufficient pieces of information and require additions to further increase the article's usefulness. The project values stubs as useful first steps toward complete articles.


Communications has merged with many previous notions:

  • Storage & distribution
  • IO (input/output)
  • Persistence & propagation
  • P2P
  • Booking/Schedule/meetings/Channels
  • λ-cache
  • Class-loops
  • Global reduction
  • It may combine further with time

Communications is one of the fundamental nodal organisations. The current nodal implementation of this concept is io.c which 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:

  • Files
  • TCP/IP streams
  • Keyboard and mouse
  • Time (integrated as spectrum)

Essentially the communications notion involves allocating resource amongst all the non-local environments - ie those which cannot be updated directly with the local nodal functions, because they are non-atomic, requiring nodal reduction to execute.

The other aspect of communications is the event-driven aspect, incoming events over various protocols results in the information being hooked into a loop 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 oricess 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 deliveery 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