Direct Communication

Release 7 introduced direct communication capabilities between two network transport objects.

Overview

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.

Usage

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.
Eligibility

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.
Restrictions

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.

Cost

Each enabled transport consumes a UDP port.

See Also

Specifying Direct Communication

Remote Daemon