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:
-
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.
- 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.
-
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.
-
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.
- Message passing is assumed to be unreliable with no guarantee of
delivery.
- 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
...
- Processes have "share nothing" semantics. This is obvious since they are imagined to run on physically separated machines.
- 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.
- 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.
-
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