Configuring Inter-Process Communications
This section discusses Inter-Process Communications configuration information that should be considered when using the C and Java RTO messaging APIs.
Context Properties that Affect IPC
The following table describes important threading model‑related context properties that affect IPC operations.
| Management Mode | Description |
|---|---|
|
C:
Java RTO:
|
Allows for control of the processor affinity for the internal context thread. The affinity is specified as a string of numbers or ranges representing CPUs, using 0-based CPU IDs. An empty string means that the affinity is not set, and the thread inherits the processor affinity from the main thread. The default value is an empty string. Support for Solaris/SunOS is now deprecated and the last release was v7.23.0 (September 2022). For more details, see the Deprecated Features list on the Product Lifecycle Policy page. |
|
C:
Java RTO:
|
Controls the processor affinity for the internal shared memory thread. This property has the same semantics as |
|
C:
Java RTO:
|
Controls the spinning or blocking behavior of the internal shared memory thread. A value of -1 causes the thread to always spin. A value greater than 0 sets the number of times to spin the thread before blocking. A value of 0 means block without spinning. The default value is 0. |
Session Properties that Affect IPC
From the viewpoint of the application, a single session is used for all of the IPC connections to peer applications (both incoming and outgoing connections). The properties for this session and how they affect the underlying sessions that provide connections to peer applications must be considered.
The following session properties should be given particular consideration.
| Property | Impact on IPC |
|---|---|
|
C:
Java RTO:
|
When using IPC to communicate with multiple peers, the In addition, if the application is not solely passive in nature, it is also used to configure a list of peer connections to create (outgoing connections). This allows a multi-point session to create a series of sub-sessions and create outgoing connections. Each hostname or IP address entry must be semicolon separated. A given entry can have a series (up to four) semi-colon-separated host entries. |
|
C:
Java RTO:
|
Ignored for IPC connections. |
|
C:
Java RTO:
|
When using a shared memory transport, this property allows the application that created the connection to control the size of the socket send buffer. The application that accepts an incoming connection that switches to shared memory has no control over the buffer sizes because it uses the shared memory channel created by the connection originator. |
|
C:
Java RTO:
|
When using a shared memory transport, this property allows the application that created the connection to control the size of the socket receive buffer. The application that accepts an incoming connection that switches to shared memory has no control over the buffer size because it uses the shared memory channel created by the connection originator. |
|
C:
Java RTO:
|
IPC applications should always enable this property. Otherwise, when a new peer connects, the existing application subscriptions are not being sent to the new peer, and as a result, the new peer will not send matching traffic to the application. |
|
C:
Java RTO:
|
When this session property is enabled (the default), the client can create a session that is allowed to have multiple underlying sessions/transports. |
Configuring the Transport Channel Type
The transport channel type used for IPC is configured through the syntax of the HOST session property. The entry for the HOST session property should provide a protocol, host, and port specified as follows:
[Protocol:]Host[:Port]
Where:
Protocol is protocol used for the transport channel. Valid values are:
tcp—Use a TCP channel for communications between the application and its peers. If no protocol is set,tcpis used as a default.shm—Use a shared memory channel for communications between the application and its peers. A TCP channel is first established, the peers then switch to a shared memory channel and tear down the TCP connection.listen—Have the session listen for and accept incoming TCP connections. The peer establishing the connection indicates whether communications should continue over TCP or be switched to shared memory communications.
Host—The IP address (or hostname) to connect to or listen to for incoming connections.
Port—The port to connect to for an outgoing TCP connection, or to listen on for incoming TCP connections. A value is only required when using a port other than the automatically assigned default port number. (The default port is 55555 when compression is not used; the default port is 55003 when compression is used.)
Examples:
The following examples show how to specify transport channel types. Unless it is otherwise specified, the default port 55555 is used.
192.168.160.28—Connect to this IP address over TCPtcp:192.168.160.28—Connect to this IP address over TCPshm:192.168.160.25—Connect to this IP address over TCP, and then switch to shared memory communications.listen:192.168.160.25:44444—Listen for incoming TCP connections on a loopback IP address, port 44444. Incoming connections can specify whether communication should continue over TCP or use shared memory.
Configuring Connections to Peer Applications
When a multi-point session accepts a new incoming connection, and internally creates a new sub-session for that new transport channel, the properties of the sub-session are inherited from the main session. This means that behavior, such as whether sends are blocking or not, is controlled by the session configured by the application.
When a session creates outgoing connections (and their associated sub-sessions) to the peers listed in the HOST session property, each sub-session for an outgoing connection inherits the session properties from the main session.
The MULTIPOINT session property is used to control whether a session uses a single transport channel or if it supports a number of underlying sessions for connections to multiple peer applications. By default, a multi-point session is enabled.
Session Events with IPC
To allow inter-process communications with multiple peer applications, there can be many sub-sessions below the session that a client application uses to establish a connection to the event broker. However, even when there are multiple sub-sessions, the client application only sees and interacts with the one session, and, as a result, it only receives session events from that single session.
When the application connects the session, it receives a session up event when the first sub-session successfully connects. There are no further session up events as more sub-sessions are established by the API. Similarly, the application only receives a re-connecting or session down event when the last sub-session is no longer established.
As a result, the application does not see, and cannot query, the status of individual IPC transports to peer applications. This view is similar to what application would have if it were communicating with other applications through an event broker, instead of communicating with them directly through IPC.