IPC(5FEA)

NAME | FEATURE SUMMARY | BASIC CONCEPTS | API | ATTRIBUTES

NAME

IPC- inter-process communication

FEATURE SUMMARY

The IPC feature provides powerful asynchronous and synchronous communication services.

The IPC feature exports the following basic communication abstractions:

• The unit of communication (message).

• Point-to-point communication endpoints (port).

• Multicast communication endpoints (groups).

When the IPC_REMOTE feature is set, IPC services are provided in a distributed, location-transparent way, allowing applications distributed across the different nodes, or sites, of a network to communicate as if they were co-located on the same node.

BASIC CONCEPTS

The IPC feature allows threads to communicate and synchronize when they do not share memory, for example when they do not run on the same node.

Communications rely on the exchange of messages through ports.

Unique identifiers

The IPC location-transparent communication service is based on a uniform global naming scheme: communication entities are named using global unique identifiers. Two types of global identifiers are distinguished: static identifiers, which are provided to the system by the applications, and dynamic identifiers, which are returned by the system to the application.

Static identifiers are built in a deterministic way from stamps provided by the applications. On a site, only one communication object can be created with a given static identifier within the same communication feature. The maximum number of static stamps is fixed.

Network-wide dynamic identifiers, assigned by the system, are guaranteed to be unique across site reboots for a long time. The dynamic identifier of a new communication object is initially only known by the actor which creates the communication object. The actor can transmit this identifier to its clients through any application-specific communication mechanism (within a message returned to the client, for instance).

Messages

A message is an untyped string of bytes of variable but limited size (64 KB), called the message body. The sender of the message may optionally join a second byte string to the message body, the message annex. The message annex has a fixed size (120 bytes). The message body and the message annex are transferred with copy semantics from the sender address space to the receiver address space.

A current message is associated with each thread. The current message of a thread is a system descriptor of the last message received by the thread. The current message is used when the thread requires to reply to the sender of the message or acquire protection information about the sender of the message. This concept of current message allows the most common case, in which threads reply to messages in the order they are received, to be optimized and simplified. However, for other cases, the kernel provides the facility to save the current message, and restore a previously saved message as the current message.

Ports

Messages are not addressed directly to threads, but to intermediate entities called ports. Ports are named using unique identifiers.

A port is an ``address'' to which messages can be sent, and which has a queue holding the messages received by the port but not yet consumed by the threads. Port queues have a fixed maximum size (system parameter).

For a thread to be able to consume the messages received by a port, it is necessary that this port be attached to the actor that supports the thread. When a port is created by a thread, the thread attaches the port to an actor (possibly different from the one that supports the thread). The port receives a local identifier, relative to the actor it is attached to.

A port can only be attached to a single actor at a time, but can be successively attached to different actors: a port can migrate from one actor to another. This migration can be accompanied, or not, by the messages already received by the port and not yet consumed by a thread. The concept of port provides the basis for dynamic reconfiguration. The extra level of indirection (the ports) between any two communicating threads means that the threads supplying a given service can be changed from a thread of one actor to a thread of another actor. This is done by changing the attachment of the appropriate port from the first thread's actor to the new thread's actor.

When an actor is created, a first port is automatically attached to it: this port is called the actor's default port. The actor's default port may not be migrated nor deleted.

Groups of ports

Ports can be assembled into groups of ports. The concept of group extends port-to-port addressing between threads by adding a multicast facility. Alternatively, functional access to a service can be selected from among a group of (equivalent) services through use of port groups.

Creating a group of ports only allocates a name for the group. Ports may then be inserted into the group: the port group is built dynamically. A port can be removed from a group. Groups may not contain other groups.

Like an actor (see the description of the CORE feature), a group is named by a capability. This capability contains a unique identifier (UI), specific to the group. This UI can be used for sending messages to the ports in the group. The full group capability is needed in order to modify the group configuration (inserting ports in and removing ports from the group).

As for ports, messages are addressed to port groups by their UI. In the case of a group UI, the address is accompanied by an address mode. The possible address modes are:

• Broadcast to all ports in the group (broadcast mode).

• Addressing one of the ports of the group, arbitrarily selected (functional mode).

• Addressing one of the ports of the group, located on the same site as a given object designated by its UI (associative functional mode).

• Addressing one of the ports of the group, assuming that the selected port UI is on a different site from that of a given UI (exclusive functional mode).

Semantics of communication

The IPC services allows threads to exchange messages in either asynchronous mode or in demand/response (that is, Remote Procedure Call (RPC)) mode.

Asynchronous mode: The sender of an asynchronous message is blocked only during the time of local processing of the message by the system. The system does not guarantee that the message has been deposited at the destination location.

RPC mode: The RPC protocol allows the construction of client-server applications, using a demand/response protocol with management of transactions. The client is blocked until a response is returned from the server, or a user-defined optional timeout occurs. RPC guarantees at-most-once semantics for the delivery of the request; it also guarantees that the response received by a client is definitely that of the server and corresponds effectively to the request (and not to a former request to which the response might have been lost.). RPC also allows a client to be unblocked (with an error result) if the server is unreachable or if the server has crashed before emitting a response.

Finally, this protocol supports the propagation of abortion through the RPC. This mechanism is called abort propagation: when a thread which is waiting for an RPC reply is aborted, this event is propagated to the thread which is currently servicing the client request.

A thread that attempts to receive a message on a port is blocked until a message is received or a user-defined optional time-out occurs. A thread may attempt to receive a message on several ports at a time. Among the set of ports attached to an actor, a subset of enabled ports is defined. A thread may attempt to receive a message sent to any of its actor's enabled ports. Ports attached to an actor may be dynamically enabled or disabled.

When a port is enabled, it receives a priority value: if several of the enabled ports hold a message when a thread attempts to receive on the enabled set of ports, the port with the highest priority is selected. The actor's default port may not be enabled.

When a port is not enabled, it is disabled. This does not mean that the port may not be used to send or receive messages. It only means that the port may not be used in multiple port receive requests. The default value is disabled.

Message handlers

As described above, the conventional way for an actor to consume messages delivered to its ports is to have threads explicitly expressing receive requests on those ports. An alternative to this scheme is the use of message handlers. Instead of explicitly creating threads, an actor may attach a handler (a routine in its address space) to the port. When a message is delivered to the port, the handler is executed within the context of a kernel-provided thread.

Message handlers and explicit receive requests are exclusive: when a message handler has been attached to a port, any attempt by a thread to receive a message on that port returns an error.

The use of message handlers is restricted to supervisor actors. It allows significant optimization of the RPC protocol when both client and server reside on the same site, avoiding thread context switches (from the kernel point of view, the client thread is used to run the handler) and memory copies (copy of the message into kernel buffers is avoided).

The way messages are consumed (threads or handler) is totally transparent for the client (the sender of messages). The strategy is selected by the server only.

Protection identifiers

The IPC feature provides a Protection Identifier (PI) to each actor and to each port. The structure of the Protection Identifiers is fixed, but the feature does not associate any semantics to their values. The kernel only acts as a secure repository for these identifiers.

An actor receives, when its IPC context is initialized, a PI equal to that of the actor that created it. A port also receives a PI equal to that of the actor that created it. A system thread can change the PI of any actor or port. Subsystem process managers are in charge of managing the values given to the PI of the actors and ports they control.

When a message is sent, it is stamped with the PI of both the sending actor and its port. These values can be read by the receiver of the message, which can apply its own protection policies and thus decide if it should reject the message. Subsystem servers may then apply the subsystem-specific protection policies, according to the PI semantics defined by the subsystem process manager.

Reconfiguration

The kernel allows the dynamic reconfiguration of services by permitting the migration of ports This reconfiguration mechanism requires both servers involved in the reconfiguration to be active at the same time.

The kernel also offers mechanisms permitting one to manage the stability of the system, even in the presence of failures of servers. The concept of port groups is used to establish the stability of server addresses. Note that a port group collects several ports together. A server that possesses a port group capability can insert new ports into the group, replacing the ports that were attached to servers that have terminated.

A client that references a group UI (rather than directly referencing the port attached to a server) can continue to obtain the needed services once the terminated port has been replaced in the group.

In other words, the lifetime of a group of ports is unlimited, because groups continue to exist even when ports within the group have terminated (logically, a group needs to contain only a single port, and this only if the server is alive). Thus clients can have stable services as long as their requests for services are made by emission of a message towards a group.

API

The IPC feature API is summarized in the following table:

Function

Comment

actorPi

Modify the PI of an actor.

portCreate

Create a port.

portDeclare

Declare a port.

portDelete

Destroy a port.

portDisable

Disable a port.

portEnable

Enable a port.

portGetSeqNum

Get a port sequence number.

portLi

Acquire the LI of a port.

portMigrate

Migrate a port.

portPi

Modify the PI of a port.

portUi

Acquire the UI of a port.

grpAllocate

Allocate a group name .

grpPortInsert

Insert a port into a group.

grpPortRemove

Remove a port from a group.

ipcCall

Send synchronously.

ipcGetData

Get the current message's body.

ipcReceive

Receive a message.

ipcReply

Reply to the current message.

ipcRestore

Restore a message as the current message.

ipcSave

Save the current message.

ipcSend

Send asynchronously.

ipcSysInfo

Get information about the current message.

ipcTarget

Construct an address.

svMsgHandler

Connect a message handler.

svMsgHdlReply

Prepare a reply to a handled message.

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Interface Stability	Evolving

NAME | FEATURE SUMMARY | BASIC CONCEPTS | API | ATTRIBUTES