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.
Figure 13 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.
To enable direct communication, specify a two-part service parameter when creating the transport object:
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:
A transport object is eligible for direct communication if it meets
all of these conditions:
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. (However, it is available for transports that connect remotely to a TIBCO Messaging Appliance P-7500.)
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.
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.
