Communications

aka persistence & propagation

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. See Wiki workflow and Wikipedia:Stub for more details on this process. See all the stubs in Category:Stubs

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

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