ProcessingModel

The processing model in the Askemos space follows the principles of the pi-calculus tries to fulfill the expectations of the xml processing model of w3c (though streaming channels are supported indirect only, since it's pretty hard to compute a checksum for them).

However a very comprehensible understanding can be gained from comparision with Erlang. Joe Armstrong wrote in Making reliable distributed systems in the presence of software errors about Erlangs design. It happens that the Askemos system has minor differences only, which stem from it's extraordinary consitency requirements.

Starting from page 22 concurency oriented programming languages (COPL) are introduced. Those characteristic apply to the Askemos system, which some exceptions. Here his properties with Askemos-related comments:

2.4.2 Characteristics of a COPL

COPLs are characterised by the following six properties:

1. COPLs must support processes. A process can be thought of as a self-contained virtual machine. Processes in Askemos are located at places.

   Erlang has -- in sharp contrast to Askemos -- only "classical" uncontrolled processes. It's hardly imaginable how those could be controled to fulfill the virtual synchrony requirements. Therefore Askemos takes a different approach, which is closer to transactional semantics and the theory of parallel processes: processes are described as sequence of process steps, which are executed in virtual synchrony.

2. Several processes operating on the same machine must be strongly isolated. A fault in one process should not adversely effect another process, unless such interaction is explicitly programmed. Askemos: fulfilled.

3. Each process must be identified by a unique unforgeable identifier. We will call this the Pid of the process. The OID's of Askemos places have this property as well. It is sufficient to fulfill the requirements set forth by the pi-calculus if process can not construct arbitrary identifiers (as in Erlang). However in a distributed system where attackers compromised a percentage of the nodes, it's however possible to construct identifiers. Furthermore Askemos-OID's are self certifying, i.e. they can be used to proof certain properties of the identified place. Therefore the Askemos system distinguishes process identifiers (OID's) and capabilities (rights), since in a distributed system under attack it is possible to forge/construct arbitrary identifiers.

4. There should be no shared state between processes. Processes interact by sending messages. If you know the Pid of a process then you can send a message to the process. As mentioned before, dependancy on un-guessable process identifiers is not sufficient under byzantine failure. The distinction between identifiers and capabilities allows to defer blocking of bogus messages to the recieving end, where the attacker has no control, since it's a virtual location existing under byzantine agreement only.

5. Message passing is assumed to be unreliable with no guarantee of delivery.
6. It should be possible for one process to detect failure in another process. We should also know the reason for failure.

Note that COPLs must provide true concurrency, thus objects represented as processes are truly concurrent, and messages between processes are true asynchronous messages, unlike the disguised remote procedure calls found in many object-oriented languages.

Note also that the reason for failure may not always be correct. For example, in a distributed system, we might receive a message informing us that a process has died, when in fact a network error has occurred.

2.4.3 Process isolation ...

1. Processes have "share nothing" semantics. This is obvious since they are imagined to run on physically separated machines.
2. Message passing is the only way to pass data between processes. Again since nothing is shared this is the only means possible to exchange data.
3. Isolation implies that message passing is asynchronous. If process communication is synchronous then a software error in the receiver of a message could indefinitely block the sender of the message destroying the property of isolation.

4. Since nothing is shared, everything necessary to perform a distributed computation must be copied. Since nothing is shared, and the only way to communicate between processes is by message passing, then we will never know if our messages arrive (remember we said that message passing is inherently unreliable.) The only way to know if a message has been correctly sent is to send a confirmation message back.

In Askemos we have this “share nothing” Semantics, but: share nothing taken literally, goes against efficiency. However in a pure functional calculus it's impossible to distinguish between shared and "copied" data. This equivalency is heavily exploited in Askemos/BALL. Since the lower level (at the CoreAPI) is pure functional we have the luxury to share equal objects without violating