The Operating system specification defines that the parties of communication are actors. The actors are contained in domains, and the communication between actors may take place in intra- or inter-domain fashion. SCHEMESTATION communication is provided as one-to-one communication (unicast). No one-to-many communication (multicast or broadcast) is available. The nature of communication is reliable message-oriented communication. (The term "reliable" shall be discussed in detail later.) Trust-based security is maintained by a special actor - altough this feature is not a requirement of this simulation.
The protocol used between domains is SCHEMESTATION Packet Protocol (SSPP) Delivering the packets to the correspondent actor inside a domain is on the addressing system's responsibility.
The networking and SSPP implementation in this this project is discussed in Networking Implementation.
The system provides the actor with the means for sending messages. These messages are referred as packets. Typically, a packet might contain an actor, that is migrating.
This simulation simulates networking on TCP/IP, which provides the required reliability.
Because an actor inside a domain is provided to have an unique specifier, it can be stated that
The networking part of the SCHEMESTATION system is however not responsible of actor level addressing - the packets contain bytestring data that is passed to the messaging system. The messaging system then extracts the actor specifier from the data.
The packet format used for communication is
If a domain receives a packet whose destination address does not match its own address, its required to retransmit the packet.
Since the protocol is on top of a reliable protocol, no acknowledgements nor check sums are used.
SCHEMESTATION is a network oriented operating system. This means that the system has to provide the agents with a kind of communication system. As the current aim of the project is to simulate the actual hardware on top of a UNIX system, the natural choice was to simulate the network traffic on top of TCP/IP. The network simulation could be done on top IP or even on top of plain hardware (eg. ethernet). We however see no point of doing this, since the aim of this project is not to rewrite network software.
During this project the communication is simulated on top of TCP, which provides the necessary reliability. (In a realistic system another, possibly a SCHEMESTATION-specific protocol could be used.)
TCP provides a reliable ground for sending packets, so the system won't try to retransmit them.
In the simulation a convention of domain addresses containing the ip-address - listened tcp-port -pair can be used. Refer Networking Implementation for further details.
The usual organization in the simulation is that one SCHEMESTATION domain is intructed to act as a domain. That is, it open a port to listen to, and accepts connections from the "client" domains. Since every domain is required to retransmit packets not destinated to itself, the router merely checks if the recipient domain is connected to it, and if it is, sends the packet to it. If a packet to domain that is not connected to the router is recevied, it is silently ignored.
The client domains (ordinary domain with no port to listen to) merely open a connection to a router (they get the address as a command line argument) and send all the packets to it. They also receive all the packets from the router.
Apart from this conection it would also be possible to organize different network topologies. Ultimately, every domain might open a direct connection to every domain it has to send packets. The simulation implements, but does not support the means for building arbitrary topologies.
Indepently from the topology, certain actions are taken whenever two domains connect each other. The domains then initiate a handshake, and after they both agree on the protocol used, they can send packet both ways. The parties can use control commands to for example close connection. Every SCHEMESTATION process must be able to deal with several connection simultaneously.
The networking module provides functions for the system to
For further details, consult Networking Implementation.
The security facilities described in [Operating system specification] are not required to be implemented in this simulation. The requirements are however described here for possible future extensions.
Security of communication in the SCHEMESTATION system is trust based. This means that every SCHEMESTATION maintains a trust table of SCHEMESTATION hosts that it trusts as a traget of migration or a source of migration.
Communications between domains are cryptographically secured. This is not enough, however, for ensuring a secure computation environment as some domains might be malicious or just untrustworthy. For this reason trust relations can be maintained between domains, and these relations can be used as a basis for deciding upon certain acts. For example, in Fig. 2 three domains are shown which have the following trust relations: Domain 1 trusts Domain 2 to be a good source and good target for migration (i.e. it is safe to move actors to run in Domain 2, and also to receive actors from Domain 2 to be executed locally). Domain 2 trusts Domain 1 similarly. However, between Domain 2 and Domain 3 migration can happen only from Domain 2 to Domain 3 as Domain 3 does not trust Domain 2 to be a good target for migration; nor does Domain 2 trust Domain 3 to be a good source. These trust relations are use by the domains to control actor migration.
External agents can connect to the domain in the same way as other domains. The external agents have their own interface module, which is described in External Agent Interface Specification.
We have considered providing the external agent interface convenient for performance reasons, but since it is not strictly necessary for the functionality of the core system (or the whole simulation), its design and implementation is scheduled to start only after the core system is up and running (recall that we have abandoned the water fall model in this project because of this kinf of issues.). We will supply more detailed information of the interface and the library as soon as the design begins.