Communications
One of the most commonly used communications tools apart from email is chat (text, voice and video) which is currently done by proprietary software such as Skype, MSN and Facebook. Recently it has become very unstable, it seems to be since Microsoft took over, but they say they've made no changes to the software. It often crashes badly on startup and also drops connections. I've been waiting patiently for a free software replacement, and this article is a repository of notes I'm collecting about such options.
FSF: Free software replacement for Skype
Skype is a proprietary Voice-over-IP program that uses a proprietary protocol. Skype is seducing free software users into using proprietary software, often two users at a time. Using proprietary phone software means that we can't be sure who is listening in, because we can't see the code. The Chinese government, for example, was found to have been spying on Skype conversations already, and they are probably not the only ones. We do not want to encourage the creation of a Skype compatible client, but instead, we want to encourage you to create, contribute to, or promote the use of free software replacements for Skype, such as Ekiga, and to encourage adoption and use of free VoIP, video, and chat protocols such as SIP and XMPP/Jingle.
Ways to help. The easiest way to help is to not use Skype and to encourage the use of a free software replacement instead. There are a number of programs, such as Ekiga, Twinkle, Coccinella, QuteCom, and SIP-Communicator that are working replacements for Skype. The Mingle project builds on Jabber to provide multiparty calling, and is supported by a grant from the NLnet Foundation. NLnet also supports the openMSRP project in this area. Users of such programs should file bug reports and feature requests to the projects. If you are not a developer, you can consider contributing to documentation and tutorials for such projects, as well as filing feature and bug requests. Developers should consider helping free software VoIP and video, chat, and multimedia communications projects.
Other options
- FSF Skype replacement projects
- Bye Bye Skype - Top Three Replacements
- Free and Open Source VOIP News
- Pichat
Old notes
|
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 | 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
