Copyright © Cloud Software Group, Inc. All Rights Reserved

Relay Agent

Relay agents support certified delivery in situations where persistent correspondents connect only intermittently to the network. This feature supports certified message delivery among laptop computers, and among persistent correspondents that run as ephemeral processes (for example, UNIX cron jobs).

For example, consider the situation in Figure 14. Mobile employees use laptop computers, connecting to the network whenever time and communications access permit. They run programs that communicate using certified message delivery. Relay agents collect messages on behalf of disconnected client programs, and deliver them when the programs reconnect. Relay agents also store certified delivery protocol state on behalf of their client programs, and resynchronize that state whenever the client reconnects.

Operation

In Figure 14, solid lines represent continuous connections, while broken lines represent intermittent connections.

The sending program on laptop A creates a CM transport, designating RAB as its relay agent. The listening program on laptop D creates a CM transport, designating RAC as its relay agent. (When both programs run in the same network, they could designate the same relay agent. In this example, the programs use separate relay agents, to illustrate that computers B and C could be in different networks.) Computers E and F remain continuously connected to the network; their programs do not require relay agents, but they can interact with RAB and RAC.

The relay agents store inbound certified messages and labeled messages (and other messages related to certified delivery features) on behalf of their disconnected client programs. When a client is connected, it receives inbound messages immediately.

 

Figure 14 Relay Agents

 

When laptop A is connected to the network, and connected to RAB, the sending program transfers its outbound certified messages to RAB, which in turn sends them to the network. When laptop A is disconnected, the program process stores its outbound certified messages; upon reconnection, it transfers the stored messages to RAB, which sends them to the network.

When laptop D is connected to the network, and connected to RAC, the listening program receives all inbound certified messages through RAC. When the connected listener confirms receipt, the confirmations flow through RAC.

In contrast, when laptop D is disconnected, the relay agent named RAC stores certified messages on behalf of the listening program; upon reconnection, RAC transfers the stored messages to the listening program.

When laptops A and D are both connected to the network, the sending program receives inbound confirmations as the listening program on D sends them (through intermediaries RAC and RAB). When laptop A is disconnected, the relay agent named RAB stores the confirmations from D; upon reconnection, it transfers the confirmations to the sending program on A. If the listener on D disconnects before confirming receipt, the listener stores the confirmations until it reconnects to RAC; upon reconnection, the listener transfers the stored confirmations to RAC.

Communication

Once a CM transport designates a relay agent, all its communications flow through that relay agent.

Each time a CM transport reconnects with the network, it attempts to contact its designated relay agent using multicast or broadcast protocol messages. After establishing contact, the program client and its relay agent use point-to-point communications to transfer messages and resynchronize protocol state information.

Protocol State

Relay agents mirror the protocol state associated with certified delivery—including registration state and message confirmation state. When the client is disconnected from the relay agent, their protocol states can diverge; they resynchronize when the client reconnects. The client CM transport is always the master of the protocol state, and the relay agent is the mirror.

Transparency

Relay agents are transparent; that is, the semantics of certified delivery, confirmation, discovery, and registration remain the same, whether or not relay agents are operating. Confirmation indicates that the certified listener has actually received the certified message (relay agents do not generate confirmations on behalf of listening clients).

Connecting and Disconnecting

A program can control the connections to its relay agent implicitly or explicitly:

•	Implicit control works best for a program that creates a new CM transport each time it establishes network connectivity.

−	Creating a CM transport implicitly connects it to its designated relay agent.

−	Destroying a CM transport implicitly disconnects it from its relay agent.

For example, consider a laptop program that the user terminates before disconnecting, and restarts after reconnecting. Even though this program embodies a persistent correspondent, it creates a new CM transport object each time it restarts.

As another example, consider an ephemeral process (such as a UNIX cron job). Each time it starts, it creates a new CM transport object, even though each instance embodies the same persistent correspondent.

•	Explicit control works best for a program that retains the same CM transport object through several cycles of intermittent network connectivity.

−	Explicitly connect each CM transport to its relay agent whenever network connectivity resumes.

−	Explicitly disconnect each CM transport from its relay agent before disconnecting from the network.

For example, consider a laptop user who connects to the network whenever a telephone line is available, yet continues to use the same program process even when the computer is physically disconnected from the network. The program can use one CM transport object for its entire process lifetime, explicitly connecting to the relay agent when the computer connects to the network, and disconnecting from the relay agent when the computer disconnects from the network.

 

Table 33 summarizes the calls that control relay agent connections—implicitly and explicitly.

Table 33 Relay Agent Connect and Disconnect Calls (Sheet 1 of 2)

C	Implicit	tibrvcmTransport_Create() tibrvcmTransport_Destroy()
	Explicit	tibrvcmTransport_ConnectToRelayAgent() tibrvcmTransport_DisconnectFromRelayAgent()
C++	Implicit	TibrvCmTransport::create() TibrvCmTransport::destroy()
	Explicit	TibrvCmTransport::connectToRelayAgent() TibrvCmTransport::disconnectFromRelayAgent()
Java	Implicit	TibrvCmTransport() TibrvCmTransport.destroy()
	Explicit	TibrvCmTransport.connectToRelayAgent() TibrvCmTransport.disconnectFromRelayAgent()
.NET	Implicit	CMTransport CMTransport.Destroy
	Explicit	CMTransport.ConnectToRelayAgent CMTransport.DisconnectFromRelayAgent

Connecting

Connect calls are non-blocking; they immediately return control to the program, and asynchronously attempt to connect to the relay agent (continuing until they succeed, or until the program makes a disconnect call).

When a CM transport attempts to connect to a relay agent, Rendezvous software automatically locates the relay agent process (if it exists). When the CM transport successfully connects to the relay agent, they synchronize:

•	The CM transport receives a RELAY.CONNECTED advisory, informing it of successful contact with the relay agent.

(When a CM transport cannot locate its relay agent, it presents a DELIVERY.NO_RESPONSE advisory; however, do not design programs to rely on this side effect.)

•	If the client transport is a CM listener, the relay agent ensures that it is listening to the same set of subjects on behalf of the client. The relay agent also updates its confirmation state to reflect the state of the program transport.

•	If the client transport is a CM sender, the relay agent updates its acceptance state to reflect the state of the program. The sending client updates its confirmation state to reflect the state of the relay agent.

•	The CM transport and relay agent exchange the data messages that they have been storing during the time they were disconnected.

 

Code programs to remain connected for a minimum of two minutes, to allow time for synchronization to complete. (Two minutes is a generous estimate, which is sufficient for most situations. Actual time synchronization time can be much shorter, and varies with the number of stored messages and the degree to which protocol state has changed.)

Disconnecting

Disconnect calls are non-blocking; they immediately return control to the program, and asynchronously proceed with clean-up tasks:

•	If the client transport is a CM listener, the relay agent attempts to synchronize its listening state with the transport (to assure that the relay agent adequately represents the CM listeners of the client).

•	The CM transport stops communicating with the relay agent.

The CM transport stores subsequent outbound events—including data messages and protocol state changes. If the CM transport is a certified sender, it stops requesting delivery confirmation for outstanding unconfirmed messages. (See also, Requesting Confirmation.)

The relay agent stores subsequent inbound events for the CM transport—including data messages and protocol state changes.

•

A CM transport that explicitly disconnects (and is not destroyed) presents a RELAY.DISCONNECTED advisory, informing the program that it is safe to sever the physical network connection. (A CM transport that implicitly disconnects during its destruction sequence will never present this advisory; instead, it is safe to sever the physical connection when the destroy call returns.)

Delays

Programs that connect only intermittently add delays to several phases of certified message delivery, including discovery and registration, delivery, and confirmation of receipt. Because of these delays, certified messages might require longer time limits than they would in the absence of relay agents.

To understand the possible sources of delays, consider this worst-case situation. Figure 15 depicts the network arrangement; Figure 16 illustrates the narrative:

1.	The CM transport on laptop D listens to the subject foo. When the listener transport connects to its relay agent (RAC), RAC begins listening on its behalf. The listener transport then disconnects from RAC.

2.	The CM transport on laptop A sends messages to the subject foo.

Although the CM send call produces a labeled message, the CM transport on D is not yet registered as a certified listener—so when it receives this message, it does not confirm receipt. By anticipating the listener and pre-registering it, the CM sender can certify this outbound message even before the listener requests registration.

When the sender transport connects to its relay agent (RAB), it transfers its stored outbound messages to RAB, which in turn sends them to the network. The sender then disconnects from RAB.

3.	RAC receives the messages from RAB, stores them for its listening CM transport client on D, and automatically requests registration on behalf of that listening client.

RAB receives the registration request, and stores it for its sending client on A.

4.	When the CM sending transport on A connects, it transfers its waiting outbound messages to RAB, and accepts the registration request.

Both RAB and RAC store the acceptance state.

From this time forward, the sender and listener transports have a certified delivery agreement (even though the listener has not yet received any notice of acceptance). Subsequent messages from the sender are certified (but messages sent previously are not certified).

Then the sender disconnects.

5.	When the listening CM transport on D connects, it transfers the acceptance state from RAC, along with stored inbound messages. The listener confirms receipt of the certified messages. Both RAB and RAC store the confirmation state.

6.	When the sending CM transport on A connects, it transfers the confirmation state from RAB.

Figure 15 Relay Agents and Delays: Network

 

Figure 16 Relay Agents and Delays: Timing

 

Notice these delays:

•	Although the listener transport begins listening at step 1, the sender transport does not receive a request for certified delivery until step 4. Messages sent before establishing the certified delivery agreement are not certified for that listener.

•	Although the sender transport begins sending certified messages at step 4, it does not receive confirmation until step 6. The message time limit must be longer than this delay, otherwise the message expires before confirmation arrives, and the sender transport presents a DELIVERY.FAILED advisory.

Capacity

Each relay agent can serve CM transports in several client programs simultaneously, limited only by the relay agent host computer and its network interface. The client CM transports of a relay agent can both send and listen.

Reply Name Substitution

Consider the intermittently connected program (A) in Figure 17. A sends a certified request message (for example, a query) and expects a reply message by listening to an inbox name (the reply can be certified or an ordinary message). When A disconnects, it becomes unavailable to receive the reply message.

To ensure that the reply arrives properly, the relay agent (RAB) establishes a surrogate inbox name, and substitutes that name as the reply name on the outbound message. When the reply arrives, RAB receives it, and substitutes the original reply inbox name before transferring the reply to A. Figure 17 illustrates this sequence.

To see why reply name substitution is important, consider the result without substitution. Suppose instead that A places the reply inbox name in a field of the request message, and sends it without a proper reply name. In this erroneous situation, the relay agent cannot intercept the reply message—so if A is disconnected when the reply is sent, A does not receive the reply.

Figure 17 Relay Agents: Reply Name Substitution

Notice that if A destroys the original inbox listener event or invalidates its transport, then it can never receive the reply message from RAB.

Notice that when the reply name is a public subject (rather than an inbox), reply name substitution is unnecessary—since the relay agent can listen to the same reply subject as A. This arrangement works properly even when A terminates and restarts, or creates a new transport.

See Also

For information about the relay agent process, see Relay Agent in TIBCO Rendezvous Administration.

 

Copyright © Cloud Software Group, Inc. All Rights Reserved