TIBRV: Remote vs Local RVD

Question

When connected to a local RVD a sending application is shielded from network interruptions and the send message methods will only block for the time it takes for the message to reach the local RVD process.

With remote RVD the sending application is no longer shielded from network interruptions and the send message methods will block for the time it takes to hop across the network to reach the remote RVD process.

Is my understanding correct? The documentation is vague regarding remote daemons.

I'm mostly concerned with how reliable and performant the send message will be from the perspective of a sending application. Introducing unnecessary blocking on the client side due to sending a message (especially a network hop) is a big no-no in this application. The speed at which the messages reach the consumer is not of the utmost importance. With this in mind is a remote RVD out of the question?

Answer 1

As soon as you cross a layer two network boundaries you should use RVRD's (Roundevouz Routing Daemon).

Within a broadcast/multicast subnet a RVD guarantees a reliable transport. The RVD receives the message over TCP (usually a local process) and then delivers it to the network. It holds the message for 60s to be able to retransmit it to other rvd/rvrd's that for some reason did not receive the message.

But as you describe it, if you connect to the RVD with TCP over a layer 3 network, you are actually doing the same job as the RVRD. The RVRD connects separate layer 2 networks using TCP.

Within a TIBRV network the local application delivers the message to the RVD/RVRD on the local machine, then the local network RVRD delivers the message to other networks over TCP, without blocking the process that originally sent the message.