When relying on shared memory technology to connect computers, or accessing data from several processes, it also becomes necessary that the ORB allows this communication means to be taken into consideration. Making the ORB communicate over shared memory is no longer a straightforward modification for two reasons: (i) the OMG architecture requires a reliable connection oriented message passing layer that the ORB uses with the General Inter ORB Protocol (GIOP). Therefore every used transport mechanism must provide functionality which resembles such a service layer. (ii) shared memory lacks a significant quality that can be found in every message-oriented environment: notification of the receiver whenever data is ready. The first requirement can be met by wrapping the shared memory and emulating a stream buffer to which a program can write and from which it can read. The advantage of shared memory is that data do not have to be copied upon receipt of a message, but may stay in the shared memory as long as they are used. ORBs generally do not reflect this fact and thus the core has to be modified in order to follow a zero-copy approach. Providing a notification mechanism is more difficult to realise. Even with synchronisation primitives like mutexes or semaphores the ORB will not work, as the concept of an address is missing. A certain minimum amount of information about the communicating participants has to be exchanged before the shared memory can be used. This includes at least the identities of peers and the memory region that is used for communication. We chose to implement the Publisher-Subscriber pattern (see figure 29) with a Unix FIFO as a means for exchanging the connection information between a sender and a receiver.
A receiver may subscribe to a number of shared memory regions. It specifies a pointer to a method that is invoked whenever data is ready. A pointer to the data is passed as a parameter to the invoked method. By following this callback approach, we avoid the overhead of demultiplexing the incoming message to the right part of the program. When a sender publishes data, it is copied into the shared memory and receiver is notified. The notification includes the identification of the shared memory region and the length of the written data.
From the performance results in figure 30 we see that the application of a zero-copy Publisher-Subscriber communication over shared memory outperforms other transport layer choices for large messages. Comparing the performance using the bare Publisher-Subscriber classes for communication with the performance of the ORB also makes the limitation of the ORB clear: we reveal a saturation in throughput with the CORBA implementation because the presentation layer engine in the receiver has to loop at least once over the incoming GIOP message. The saturation is also visible when using pipes or sockets directly. These layers are non zero-copy and therefore the receiver copies the message always into a buffer provided by the application programmer. The memory access operation represents a natural upper limit for throughput. Taking a closer look at the right plot in figure 30 we get a better impression of what happens to small messages that are transferred using shared memory.
Summing up, we can say that shared memory communication with the ORB does not perform well compared to the application of pipes. For each message sent over shared memory, a notification of the subscriber that is registered for the memory region has to be made. This notification is done by using a pipe. Therefore sending the small message in the pipe directly gives better performance. Before we come to a conclusion from these tests, we would like to shed light on another issue: scalability of the server.
