Open topic with navigation

TIBCO Rendezvous® 8.7.0

# 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

Did you find this helpful?

Yes No
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO Rendezvous®

Copyright © 1997-2023. Cloud Software Group, Inc. All Rights Reserved.