Direct Communication
Release 7 introduced direct communication capabilities between two network transport objects.
With direct communication, two application programs can conduct eligible point-to-point communications without intermediary Rendezvous daemon (rvd
) processes. This arrangement can decrease message latency and context switching for point-to-point messages.
Direct Communication between Two Programs contrasts the route of a point-to-point message with direct communication against the same message with regular communication (through rvd
). In the path through rvd
, each of the two daemons could add a small delay. The direct path avoids these sources of potential delay.
Figure 26: Direct Communication between Two Programs
Direct communication uses RPTP over a UDP channel.
To enable direct communication, specify a two-part service
parameter when creating the transport object:
• | The first part controls regular communication—including messages to public subjects and ineligible point-to-point messages. |
• | The second part controls direct communication—messages to inbox subjects at eligible destination transports. |
All eligible messages automatically use direct communication, traveling directly between the two programs. All ineligible messages flow through rvd
.
A message is eligible for direct communication if it meets all of these conditions:
• | The message has an inbox destination subject. |
• | Its sending transport object is eligible and enabled. |
• | Its receiving transport object is eligible and enabled. |
• | The network path between the sender and the receiver does not cross through Rendezvous routing daemon (rvrd ). |
A transport object is eligible for direct communication if it meets all of these conditions:
• | The transport is enabled for direct communication (that is, it has a two-part service parameter). |
Note that a program can enable a transport only if program links release 7 (or later) of the Rendezvous API library.
• | The transport connects to a local daemon. |
Both the sending and receiving transport objects must enable direct communication. If only one of the two transports enables direct communication, then point-to-point messages between them flow through rvd
.
Direct communication is not available for transport objects that connect to remote daemons.
When the path between two transports crosses a routing daemon (rvrd
), direct communication is not available between those transports. Even if both transports enable direct communication, point-to-point messages still flow through rvd
and rvrd
.
Direct communication applies only to point-to-point messages (that is, messages with inbox destinations) between two enabled transports.
Nonetheless, messages on a virtual circuit always travel point-to-point—even messages with public subject names. The virtual circuit terminals wrap all messages within internal point-to-point messages. So a virtual circuit that employs enabled transports at both terminals always reaps the benefits of direct communication.
Each enabled transport consumes a UDP port.