2 Some Ibis concepts

2.1 The Ibis Portability Layer

An important part of the Ibis system consists of the Ibis Portability Layer (IPL). The IPL consists of a set of Java interfaces and classes that define how an Ibis application can make use of the Ibis components. The Ibis application does not need to know which specific Ibis implementations are available. It just specifies some properties that it requires, and the Ibis system selects the best available Ibis implementation that meets these requirements.

2.2 An Ibis Instance

A loaded Ibis implementation is called an Ibis instantiation, or Ibis instance. An Ibis instance is identified by a so-called Ibis identifier. An application can find out which Ibis instances are present in the run by supplying a so-called ResizeHandler. This ResizeHandler is an object with, among others, a joined() method which gets called by the Ibis system when a new Ibis instance joins the run. The Ibis identifier of this new Ibis is a parameter to the joined() method.

2.3 Send Ports and Receive Ports

The IPL provides primitives to communicate between send and receive ports. In general a connection can be between multiple send ports and multiple receive ports, but the user may specify that a connection will have only a single send or receive port, allowing Ibis to choose a more efficient implementation. A connection is always unidirectional; reverse connections are conceptually totally independent.

All send and receive ports have a type which is represented by an instance of ibis.ipl.PortType. To create a connection, an Ibis application requests new send and receive ports from such a port type, and requests that a connection is set up between these ports.

To send a message, the Ibis application requests a new write message from a send port, puts data in this write message using the provided methods, and invokes the finish() method to send the message.

To receive a message, the IPL provides two mechanisms:

explicit receipt

when a receive port is configured for explicit receipt, a message can be received with the receive port's blocking receive method, or with its non-blocking poll method. These methods return a read message object, from which data can be extracted using its read methods. The poll method may also return null, in case no message is available.

upcalls

when a receive port is configured for upcalls, the Ibis application provides an upcall method, which is to be called when a message arrives. The upcall provides the message received as a parameter. The message contents will be lost when the upcall returns, so the data in the message must be read in the upcall. Upcalls are either automatic, or must be polled for explicitly, see Section 3.2.

2.4 Port Types

Send and receive ports are typed by means of a port type. A port type is defined and configured with properties. Only ports of the same type can be connected. Port type properties that can be configured are, for instance, the serialization method used, reliability, whether a send port can connect to more than one receive port, whether more than one send port can connect to a single receive port, et cetera.

2.5 Serialization

Serialization is a mechanism for converting Java objects into portable data that can be stored or transferred. Java has input (java.io.ObjectInputStream) and output (java.io.ObjectOutputStream) streams for reading and writing objects. In Ibis, we call this mechanism Sun serialization. Ibis also has its own mechanism, which is completely compatible (with regard to its interface) with Sun serialization, but more efficient. We call this mechanism Ibis serialization.

Sometimes, object serialization is not needed. For that case, two simpler serialization mechanisms are available: data serialization which allows for sending/receiving data of basic types and arrays of basic types (similar to java.io.DataInputStream and java.io.DataOutputStream), and byte serialization which only allows sending/receiving bytes and arrays of bytes.