RV Administration

TIBCO Rendezvous™
Administration
Software Release 7.2
August 2003
Important Information
SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH
EMBEDDED OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY
(OR PROVIDE LIMITED ADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE.
THE EMBEDDED OR BUNDLED SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY
ANY OTHER TIBCO SOFTWARE OR FOR ANY OTHER PURPOSE.
USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND
CONDITIONS OF A LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED
SOFTWARE LICENSE AGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT,
THE CLICKWRAP END USER LICENSE AGREEMENT WHICH IS DISPLAYED DURING
DOWNLOAD OR INSTALLATION OF THE SOFTWARE (AND WHICH IS DUPLICATED IN THE
BOOK TIBCO Rendezvous Concepts). USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS
AND CONDITIONS, AND YOUR USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND
AN AGREEMENT TO BE BOUND BY THE SAME.
This document contains confidential information that is subject to U.S. and international copyright
laws and treaties. No part of this document may be reproduced in any form without the written
authorization of TIBCO Software Inc.
TIB, TIBCO, Information Bus, The Power of Now, TIBCO Adapter, and TIBCO Rendezvous are
either registered trademarks or trademarks of TIBCO Software Inc. in the United States and/or
other countries.
All Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems,
Inc. in the U.S. and other countries.
All other product and company names and marks mentioned in this document are the property of
their respective owners and are mentioned for identification purposes only.
This software may be available on multiple operating systems. However, not all operating system
platforms for a specific software version are released at the same time. Please see the readme.txt file
for the availability of this software version on a specific operating system platform.
THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.
THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL
ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE
CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCO
SOFTWARE INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S)
AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANY TIME.
Copyright © 1997–2003 TIBCO Software Inc. ALL RIGHTS RESERVED.
TIBCO Software Inc. Confidential Information
1
| iii
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Manual Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
TIBCO Product Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
How to Contact TIBCO Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Chapter 1 Do This First—Administrator’s Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Install the Rendezvous Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Install License Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Enable Access to Executable Binary Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Microsoft Windows Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
UNIX Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
VMS Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Add Service Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
UNIX Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Microsoft Windows Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
VMS Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Enable Packet Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Arrange Internetwork Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Register NT Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
File Descriptor Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapter 2 Licensing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Licensing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
License Ticket Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
License Ticket File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Ticket File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Finding the License Ticket File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Purchasing License Tickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Company and Contact Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
TIBCO Rendezvous Administration

iv
| Contents
License Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Chapter 3 Network Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Transport Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Service Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Interaction between Service and Network Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Specifying the UDP or PGM Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Network Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Constructing the Network Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Multicast Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Limitation on Computers with Multiple Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Daemon Client Socket—Establishing Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Specifying a Local Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Remote Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Default Port and Service Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Disabling Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Chapter 4 Rendezvous Daemon (rvd). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

rvd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Reliability and Message Retention Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Log Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Log Rotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Current Log Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Browser Administration Interface—rvd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Client Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Service Detail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Chapter 5 Routing Daemon (rvrd). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Routing Daemon Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Local Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Neighbor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Contents v
|
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Routing Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Neighbor Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Subject Gating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Subject Interest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Restricting Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Restricting Messages by Service or Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Restricting Messages by Subject Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
rvrd Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Initial State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Administration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
HTTP Administration Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Routing Table Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Routing Table Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Router Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Local Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Local Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Network and Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Local Network Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Subject Gating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Subject Filtering with Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Fixed Subject Interest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Neighbor Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Local Connection Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Remote Connection Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Network Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Data Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Adding Neighbor Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Active Neighbor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Passive Neighbor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Accept Any as Neighbor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Seek Neighbor with Any Name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Redundant Routing Daemons for Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Independent Routing Table Entries in One Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Overlapping Subject Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Bandwidth Contention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Defeating Independence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Common Topology Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Neighbors on the Same Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

vi
| Contents
Duplicating Effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Security and Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Neighbors Across a Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Connecting PGM and TRDP Networks with Routing Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Backlog Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Idle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Routing Daemon Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Interpreting Log Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
rvrd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Browser Administration Interface—rvrd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Local Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Connected Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Neighbor Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Daemon Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Administrator and Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Local Networks Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Subject Gating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Neighbor Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Existing Neighbor Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Add New Neighbor Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Certificate Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Certificate List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Chapter 6 Secure Daemons (rvsd and rvsrd) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Secure Daemon Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Secure Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Restricting Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Plaintext Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
rvsd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
rvsrd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Certificate Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
User Name and Password Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Contents vii
|
Limiting Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Network and Service Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Subject Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Security Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Store Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Core-Dump Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Daemon Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Behavioral Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Automatic Start and Stop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Subject Gating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Default Network and Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Browser Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
rvsd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
rvsrd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Browser Administration Interface—rvsd and rvsrd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Daemon Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Administrator and Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Default Network and Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Add a New User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Existing Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Authorize Network and Service Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Authorize Subjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Certificate Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Certificate List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Chapter 7 Relay Agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

rvrad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Chapter 8 Rendezvous Agent (rva) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

rva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Web Site Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Home Computer and Port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Isolate External from Internal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
HTTP Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

viii
| Contents
Chapter 9 Current Value Cache. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Resource Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Avoid Duplicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Ensure Continuous Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Crossing Network Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
rvcache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Chapter 10 Performance Assessment (rvperf) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Principles of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Listeners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Single Mode and Automatic Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Automatic Mode—Binary Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Dataloss Advisory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Multicast, Broadcast, Point-to-Point and Direct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Before You Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Test in an Insulated Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
rvd Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
rvperfm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
rvperfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Interpreting the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Certified Delivery Agreements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Elapsed Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Usage and Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Hardware Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Maximum Sustained Send Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Optimal Sustained Receive Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Fixed Receive Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Wide Area Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Certified Message Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Number of Certified Receivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Ledger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Very Large Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Sufficiency and Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Contents ix
|
Locating Performance Obstacles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Chapter 11 Protocol Monitor (rvtrace) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Snapshots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Range Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Protocol Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Interface Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Platform Support and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Passive Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Performance Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
The pcap Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Obtaining pcap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Packet Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Data Capture Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Output File Rotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
rvtrace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Interpreting the Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
General Network Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Number of Senders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Scanning for Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Bad Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Multicast Data Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Gaps Diagnoses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Multicast Retransmit Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Diagnoses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Point-to-Point Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Nak Diagnoses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Subject Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Subject Table Diagnoses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
SNMP Agent Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Chapter 12 Perl 5 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Features and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

x
| Contents
Installing the Perl 5 Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Using the Perl 5 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Perl Example Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Chapter 13 Certified Message Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

Forward RVCM Administrative Messages across Network Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Ledger File Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Chapter 14 Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Network Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Forward Fault Tolerance Messages across Network Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Chapter 15 Distributed Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Forward Administrative Messages across Network Boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Appendix A Windows Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

rvntscfg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
rvntsreg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Appendix B Changes in Release 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

| xi
Figures
Figure 1 Disabling Multicast: Public Subjects Still Flow Among Local Clients . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 2 Disabling Multicast: Routing Daemons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figure 3 rvd Navigation Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Figure 4 rvd General Information Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Figure 5 rvd Clients Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figure 6 rvd Client Detail Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 7 rvd Services Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figure 8 rvd Service Detail Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 9 rvd Hosts Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figure 10 Routing Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 11 Fault Tolerance among Routing Daemons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 12 Path Cost and Subject Import Weight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Figure 13 Routing Daemons Merge Subject Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Figure 14 Independent Routing Table Entries Keep Subject Spaces Separate. . . . . . . . . . . . . . . . . . . . . . . 79
Figure 15 Mutual Neighbors Merge Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Figure 16 Erroneous Neighbors on the Same Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Figure 17 Routing Daemons and Duplication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Figure 18 Routing Daemon WAN with Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figure 19 Bridge PGM and TRDP Networks with rvrd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Figure 20 rvrd Navigation Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Figure 21 rvrd General Information Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Figure 22 rvrd Local Networks Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Figure 23 rvrd Connected Neighbors Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Figure 24 rvrd Neighbor Statistics Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Figure 25 rvrd Daemon Parameters Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Figure 26 rvrd Routers Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Figure 27 rvrd Local Networks Configuration Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Figure 28 rvrd Subject Gating Configuration Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

xii
| Figures
Figure 29 rvrd Neighbor Interfaces Page—Existing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Figure 30 rvrd Neighbor Interface Configuration Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Figure 31 rvrd Certificate Uses Form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Figure 32 rvrd Certificate List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Figure 33 rvsd—Secure Connections across Single Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Figure 34 rvsrd—Secure Connections across Double Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Figure 35 rvsd Navigation Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Figure 36 rvsrd Navigation Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Figure 37 rvsd General Information Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Figure 38 Secure Daemon Administrator and Password Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Figure 39 Secure Daemon Default Network and Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Figure 40 Secure Daemon Users Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Figure 41 Secure Daemon Authorize Network and Service Pairs Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Figure 42 Secure Daemon Authorize Subjects Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Figure 43 rvsrd Certificate Uses Form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Figure 44 rvsrd Certificate List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Figure 45 Typical rva Web Site with Double Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Figure 46 Transparent Caching by rvcache. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Figure 47 Query and Response with rvcache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Figure 48 Report from rvperfm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Figure 49 Report from rvperfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Figure 50 rvtrace Output with -addrinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Figure 51 rvtrace Output without -addrinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Figure 52 Multicast and Broadcast Data Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Figure 53 Multicast Retransmit Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Figure 54 Rseq Reveals Difficulty at a Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Figure 55 Rseq Reveals Difficulty at a Sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Figure 56 Point-to-Point Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Figure 57 Nak Indicates Faulty Network Card or Infrastructure Component . . . . . . . . . . . . . . . . . . . . . . . . . 258
Figure 58 Subject Statistics—Multicast and Broadcast Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

| xiii
Tables
Table 1 Specify UDP or PGM Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Table 2 Specify Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Table 3 Default HTTP Port Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Table 4 Default UDP or PGM Service Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 5 Default TCP Port Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 6 Importing Wildcard Subjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Table 7 Four Neighbor Interface Configuration Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Table 8 Filter Expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Table 9 Multicast Data Statistics—Column Headings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Table 10 Multicast Retransmit Statistics—Column Headings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Table 11 Point-to-Point Statistics—Column Headings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Table 12 Subjects Statistics—Column Headings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Table 13 SNMP Objects in rvTrace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Table 14 SNMP Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Table 15 Critical Subjects for Certified Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Table 16 Critical Subjects for Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Table 17 Critical Subjects for Distributed Queues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

xiv
| Tables

| xv
Preface
This manual explains administration of TIBCO Rendezvous™ software and the

distributed systems that use it. It is part of the documentation set for Rendezvous
Software Release 7.2.
Parts of this book describe the configuration of Rendezvous components using a
graphical browser administration interface. The book TIBCO Rendezvous
Configuration Tools describes a programmer interface and an XML tool for
configuring the same parameters.
Topics
• Manual Organization, page xvi

• Related Documentation, page xviii
• How to Contact TIBCO Customer Support, page xx

xvi
| Preface
Manual Organization
This book begins with important information for system administrators:

• Chapter 1, Do This First—Administrator’s Checklist, on page 1
• Chapter 2, Licensing Information, on page 11
The third chapter describes several details upon which programmers and
administrators must agree for correct program operation:
• Chapter 3, Network Details, on page 17
The next several chapters describe Rendezvous components that run as

executable processes. Administrators must ensure correct set-up and operation of
these components:
• Chapter 4, Rendezvous Daemon (rvd), on page 35
• Chapter 5, Routing Daemon (rvrd), on page 57
• Chapter 6, Secure Daemons (rvsd and rvsrd), on page 127
• Chapter 7, Relay Agent, on page 165
• Chapter 8, Rendezvous Agent (rva), on page 169
• Chapter 9, Current Value Cache, on page 181
Two chapters describe utilities for measuring overall system capacity and
performance, and for diagnosing network problems.
• Chapter 10, Performance Assessment (rvperf), on page 195
• Chapter 11, Protocol Monitor (rvtrace), on page 225
Many administrators use the Perl programming language for system

administration tasks. A brief chapter describes the Rendezvous Perl API:
• Chapter 12, Perl 5 Interface, on page 271
Additional administrative tasks apply when distributed systems use advanced

features of Rendezvous software:
• Chapter 13, Certified Message Delivery, on page 277
• Chapter 14, Fault Tolerance, on page 281
• Chapter 15, Distributed Queues, on page 285

Manual Organization xvii
|
To register Rendezvous software with the Microsoft Windows operating system,

use these utilities:
• Appendix A, Windows Services, page 289
Architectural changes in release 6 lead to several important changes for

administrators:
• Appendix B, Changes in Release 6, on page 293

xviii Preface
|
Related Documentation
This section lists documentation resources you may find useful.
TIBCO Product Documentation

The following documents form the Rendezvous documentation set:
• TIBCO Rendezvous Concepts
Read this book first. It contains basic information about Rendezvous
components, principles of operation, programming constructs and
techniques, advisory messages, and a glossary. All other books in the
documentation set refer to concepts explained in this book.
• TIBCO Rendezvous C Reference
Detailed descriptions of each datatype and function in the Rendezvous C API.
Readers should already be familiar with the C programming language, as well
as the material in TIBCO Rendezvous Concepts.
• TIBCO Rendezvous C++ Reference
Detailed descriptions of each class and method in the Rendezvous C++ API.
The C++ API uses some datatypes and functions from the C API, so we
recommend the TIBCO Rendezvous C Reference as an additional resource.
Readers should already be familiar with the C++ programming language, as
well as the material in TIBCO Rendezvous Concepts.
• TIBCO Rendezvous Java Reference
Detailed descriptions of each class and method in the Rendezvous Java
language interface. Readers should already be familiar with the Java
programming language, as well as the material in TIBCO Rendezvous Concepts.
• TIBCO Rendezvous .NET Reference
Detailed descriptions of each class and method in the Rendezvous .NET
interface. Readers should already be familiar with either C# or Visual Basic
.NET, as well as the material in TIBCO Rendezvous Concepts.
• TIBCO Rendezvous COM Reference
Detailed descriptions of each class and method in the Rendezvous COM
component. Readers should already be familiar with the programming
environment that uses COM and OLE automation interfaces, as well as the
material in TIBCO Rendezvous Concepts.

Related Documentation xix
|
• TIBCO Rendezvous Administration

Begins with a checklist of action items for system and network administrators.
This book describes the mechanics of Rendezvous licensing, network details,
plus a chapter for each component of the Rendezvous software suite. Readers
should have TIBCO Rendezvous Concepts at hand for reference.
• TIBCO Rendezvous Configuration Tools
Detailed descriptions of each Java class and method in the Rendezvous
configuration API, plus a command line tool that can generate and apply
XML documents representing component configurations. Readers should
already be familiar with the Java programming language, as well as the
material in TIBCO Rendezvous Administration.
• TIBCO Rendezvous Installation
Includes step-by-step instructions for installing Rendezvous software on
various operating system platforms.

xx
| Preface
How to Contact TIBCO Customer Support
For comments or problems with this manual or the software it addresses, please
contact TIBCO Support Services as follows.
• For an overview of TIBCO Support Services, and information about getting
started with TIBCO Product Support, visit this site:
http://www.tibco.com/services/support/default.jsp
• If you already have a valid maintenance or support contract, visit this site:
http://support.tibco.com
Entry to this site requires a username and password. If you do not have a
username, you can request one.

|1
Chapter 1 Do This First—Administrator’s Checklist
This checklist outlines several important tasks for system administrators.

We recommend that you review this checklist when you install TIBCO
Rendezvous™ software on any of your networks, when you add new networks,
when you add new platforms to your networks, when you reconfigure networks,
and whenever users report problems with Rendezvous software.
Topics
• Install the Rendezvous Software, page 2

• Install License Tickets, page 3
• Enable Access to Executable Binary Files, page 4
• Add Service Entries, page 5
• Enable Packet Checksums, page 6
• Arrange Internetwork Communications, page 7
• Register NT Services, page 8

2
| Do This First—Administrator’s Checklist
Install the Rendezvous Software
Install Rendezvous software at your site. The book TIB/Rendezvous Installation

describes the installation procedure on various hardware and operating system
platforms.

Install License Tickets 3
|
Install License Tickets
If you obtained an evaluation copy of Rendezvous software, your licenses are

valid for a limited period of time (usually 60 minutes). You do not need to take
further action to use the evaluation license. To purchase licenses, contact TIBCO
Rendezvous licensing.
If you purchased licenses for Rendezvous components, you must install them in
the license ticket file (tibrv.tkt).
The license ticket file must be accessible by components that read them. Ensure
that the execution path of each user includes the directory that contains the
license ticket file.
For more information, see Chapter 2, Licensing Information, on page 11.

4
Enable Access to Executable Binary Files
Microsoft Windows Platforms

Skip this step—it is done automatically during the installation procedure.
UNIX Platforms
Add the Rendezvous binary directory to the execution path of each programmer
and end user of Rendezvous programs. The exact directory name varies
depending on where you installed Rendezvous; the installation procedure prints
the correct location for your convenience (usually a name constructed like
<installation_point>/tibco/tibrv/bin).
VMS Platforms
Place this definition in the startup file:
@SYS$STARTUP:TIBRV_STARTUP.COM
The startup file is SYS$STARTUP:SYSTARTUP_VMS.COM.

Then ensure that the following line appears in the login.com file of each VMS
programmer and end user of Rendezvous programs:
@TIBRV:[COM]TIBRV_SETUP.COM

Add Service Entries 5
|
Add Service Entries
Rendezvous transports use the service rendezvous as a default (when

programmers do not explicitly specify a service). If rendezvous is not defined as a
service, the secondary default is UDP port 7500, or PGM port 7550.
We recommend that you define rendezvous as a service name in your network
database. If port 7500 is already in use on your network, you must define
rendezvous as a service (designating an available port number). The examples
below define rendezvous as port 7500, but you may use any UDP port number.
Some organizations may want to define additional services to segregate
Rendezvous communications. For example, by convention, fault tolerance
messages between Rendezvous components use service 7504. You may also
define those services at this time. For more information, see Service Selection on
page 20.
On all platforms, Rendezvous software obtains service names by calling the
function getservbyname(). Ensure that this function returns the correct port
numbers.
UNIX Platforms
Add these definitions to the services database:
rendezvous 7500/udp
rendezvous-ft 7504/udp
Microsoft Windows Platforms

On all supported Windows platforms, add these definitions to the services
database:
rendezvous 7500/udp
rendezvous-ft 7504/udp
VMS Platforms
On VMS platforms define a service by entering these commands:
$ UCX SET SERVICE RENDEZVOUS/PORT=7500/PROTOCOL=UDP -
/USER=SYSTEM/FILE=SYS$STARTUP:TIBRV_STARTUP.COM/PROCESS=TIBRV
$ UCX SET SERVICE RENDEZVOUS-FT/PORT=7504/PROTOCOL=UDP -
/USER=SYSTEM/FILE=SYS$STARTUP:TIBRV_STARTUP.COM/PROCESS=TIBRV

6
Enable Packet Checksums
Rendezvous software requires that the operating system compute packet

checksums. You must configure the operating system to enable packet checksums
on every host computer that runs Rendezvous programs or executable
components.
Most operating systems enable packet checksums by default. Nonetheless, we
recommend that you ensure that this setting is still in effect.

Arrange Internetwork Communications 7
|
Arrange Internetwork Communications
This step extends the Rendezvous software from intranetwork message exchange
to internetwork message exchange.
• If you plan to run Rendezvous programs on a single network, you may skip
this step.
• If you plan to link several networks, read Chapter 5, Routing Daemon (rvrd),
on page 57.
• If you plan to link a web site, also read Chapter 8, Rendezvous Agent (rva), on
page 169.
Arrange your network appropriately.

8
Register NT Services
This step applies only to Microsoft Windows NT, 2000 and XP.
Some situations require certain Rendezvous components to start automatically.

You can satisfy this requirement by registering those components with the
Windows service manager. For example:
• Start a permanent rvd process so that remote client programs can connect to
it.
• Start rva so Java client programs can connect to it.
• Start rvrd without operator intervention.
To facilitate registry with the Windows service manager, the Rendezvous \bin
directory includes the utility programs rvntscfg.exe and rvntsreg.exe.
See Also
rvntscfg on page 290
rvntsreg on page 291

File Descriptor Limits 9
|
File Descriptor Limits
On UNIX, VMS, OS/400 and OS/390 platforms, the operating system can limit
the maximum number of file descriptors per process, as well as the total number
of file descriptors summed over all processes. Because each connection uses a file
descriptor, this limitation in turn limits the capacity of Rendezvous components:
• In rvd and its variants, it limits the maximum number of client connections
(that is, transports) that a daemon can accept.
• In rvrd and its variants, it limits the combined total of neighbor connections
and client connections.
• In rva, it limits the maximum number of client connections.
• In client programs, it limits the number of transport objects.
Symptoms When operating system file descriptor limits are set too low, Rendezvous
components might report errors indicating that too many files are open, or that
file descriptor limits have been exceeded. In many situations, you can eliminate
this problem by raising the limit.
VMS limits the number of open sockets, rather than file descriptors. The
consequent limitations, symptoms and remedy are analogous.

10

| 11
Chapter 2 Licensing Information
Administrators must arrange licenses and license tickets for each host computer.
Licensing Framework
In Rendezvous release 6 (and later) we changed the details of licensing and
license tickets. Please read this chapter to familiarize yourself with the new
framework.
Topics
• Licensing Overview, page 12

• License Ticket File, page 13
• Purchasing License Tickets, page 16

12
| Licensing Information
Licensing Overview
License tickets authenticate and activate licenses.

Each of these components is licensed separately—you pay separate fees and
receive separate license tickets for each component:
• Rendezvous daemon (rvd)
• Rendezvous routing daemon (rvrd)
Running rvrd as a fault-tolerant pair consumes two rvrd licenses—one for
each member of the fault tolerance group.
• Rendezvous agent (rva)
• Rendezvous current value cache (rvcache)
• Rendezvous protocol monitor (rvtrace)
License Ticket Types

Standard licenses assign a separate license ticket to each host computer.
A site license assigns a single license ticket for a very large site; each host checks
its own ticket file, which contains a copy of the site ticket.
Temporary licenses permit customer evaluation; they expire, either on a fixed
calendar date, or a specific number of minutes after starting.

License Ticket File 13
|
License Ticket File
Each host computer must keep a license ticket file. The file tibrv.tkt must
contain a ticket for each daemon component that runs on that computer.
To put new license tickets into effect, stop and restart the licensed components.
Ticket File Syntax

• Each line in the ticket file represents one license ticket.
• A license ticket consists of four fields, delimited by whitespace.
• The first field is the component or product name, such as rvd, or rvrd.
• The second field is the serial number of the license.
• The third field specifies the expiration of the license, in one of these formats:
— never (license never expires)
— 2005-11-01 (license expires on a specific date; in this example, November
1, 2005)
— start+60 (license expires 60 minutes after start time)
• The fourth field is a digital signature that validates the license.
• Programs that read the license ticket file ignore empty lines, extra whitespace,
and anything to the right of a # character (comments).
• All fields are case sensitive.
Finding the License Ticket File

The license ticket file must be accessible by all Rendezvous daemon components.
Ensure that the execution path of each user includes the directory that contains
the license ticket file.
If a component cannot find an appropriate license ticket, the component runs for
no more than 10 minutes.

14
UNIX Platforms
On UNIX platforms, the Rendezvous daemon searches for the license ticket file
(tibrv.tkt) in the directories listed in the PATH environment variable. The
Rendezvous installation procedure places the file tibrv.tkt (containing
temporary license tickets) in the bin subdirectory of the Rendezvous directory.
However, it does not overwrite an existing license ticket file. You must add that
directory to the PATH variable manually (unless it is already present).
Windows Platforms
On Microsoft Windows platforms, the Rendezvous daemon searches for the
license ticket file (tibrv.tkt) in the directories listed in the PATH environment
variable. The Rendezvous installation procedure places the file tibrv.tkt
(containing temporary license tickets) in the bin subdirectory of the Rendezvous
directory, and adds that directory to the PATH variable. However, it does not
overwrite an existing license ticket file.
VMS Platforms
On VMS platforms, the Rendezvous daemon searches for the license ticket file
(tibrv.tkt) in two ways.
• If you do not define a PATH specifier, then the daemon searches for the ticket
file in the current default directory. When a Rendezvous client program starts
the daemon automatically, or when the system startup file starts the daemon,
then the default directory is TIBRV:[BIN].
• If you do define a PATH specifier, then the daemon searches in that directory.
VMS searches for a PATH specifier in this order—first as a logical name, then as a
local DCL symbol, then as a global DCL symbol. Consider these examples.
define PATH tibrv:[bin] As a logical name.
PATH := tibrv:[bin] As a local DCL symbol.
PATH :== dka300:[tibco.tibrv.bin] As a global DCL symbol.
PATH := "/tibrv/bin/" Using UNIX syntax.
PATH := "/dka300/tibco/tibrv/bin/" Using UNIX syntax.
Installing Rendezvous creates the logical name TIBRV; the first and fourth of these
examples use that logical name.
When using UNIX syntax, the path must terminate with a slash, and must be
enclosed in quotes, as in the fourth and fifth examples.

License Ticket File 15
|
The Rendezvous installation procedure for VMS places a sample license ticket file
in the tibrv:[bin] directory as tibrvtkt.smp. If the computer does not already
have a license ticket file, you can copy this sample to tibrv.tkt to use temporary
licenses. Installation does not create a tibrv.tkt file.

16
Purchasing License Tickets
To purchase license tickets, contact TIBCO Rendezvous Licensing (via web, email,
phone or fax) and provide details of your purchase order.
Company and Contact Information

Information about your company and a contact person helps us keep in touch. We
use it to send you license tickets, documentation, notices of software updates,
announcements of new features, and other useful items.
• Company name.
• Your name (or the contact person to whom we should send all Rendezvous
correspondence).
• Your phone number (or the number of the contact person).
• Your fax number (or the fax number of the contact person).
• Your postal address (or the mailing address of the contact person; please
include the country and postal codes as applicable).
• Your e-mail address (or the address of the contact person).
License Information
License information helps us create the correct number of licenses, and issue
appropriate license tickets.
• Total Rendezvous licenses for each licensed Rendezvous component (for
example, rvd, rvrd, rva, rvcache, rvtracer).

| 17
Chapter 3 Network Details
Rendezvous software hides most networking details from applications

programmers. In some cases (in cooperation with network and system
administrators), programmers may supply three optional networking
parameters—network, service and daemon—to the transport creation calls. This
chapter describes those parameters for the administrator.
The book TIBCO Rendezvous Concepts describes these parameters in even greater
detail than this chapter. See also these sections:
• Service Parameter on page 103 in TIBCO Rendezvous Concepts
• Network Parameter on page 107 in TIBCO Rendezvous Concepts
• Daemon Parameter on page 110 in TIBCO Rendezvous Concepts
Topics
• Transport Parameters, page 18

• Service Selection, page 20
• Network Selection, page 23
• Daemon Client Socket—Establishing Connections, page 28
• Default Port and Service Numbers, page 30
• Disabling Multicast, page 32

18
| Network Details
Transport Parameters
Network transport creation calls accept three parameters that govern the behavior
of the Rendezvous daemon: service, network and daemon. In simple networking
environments, the default values of these parameters are sufficient (in C, the
program can supply NULL for all three).
Most programmers will use default values for these parameters unless advised
otherwise by their network administrator. To determine whether your
environment requires special treatment, consider whether any of these conditions
apply:
• Several independent distributed applications run on the same network, and
you must isolate them from one another (service parameter).
• Programs use the Rendezvous routing daemon, rvrd, to cooperate across a
WAN with programs that belong to a particular service group, and the local
programs must join the same service group (service parameter).
• A Rendezvous program runs on a computer with more than one network
interface, and you must choose a specific network for Rendezvous
communications (network parameter).
• Computers on the network use multicast addressing to achieve even higher
efficiency, and programs must specify a set of multicast groups to join
(Network parameter).
• A program runs on one computer, but connects with a Rendezvous daemon
process running on a different computer, and you must specify the remote
daemon to support network communications (daemon parameter).
• Two programs use direct communication. Both programs must enable this
feature and specify its service (service parameter).
If none of these conditions apply, then programmers can use default values for the
transport parameters.
If your network environment requires special treatment for any these parameters,
please notify applications programmers developing software for your
environment. If your organization runs Rendezvous programs developed by a
third party, consult the third-party documentation for information about network
and service configuration.
In addition, certain components of Rendezvous software, local programs and
third-party programs may also require special configuration:

Transport Parameters 19
|
• The Rendezvous routing daemon, rvrd, must specify the service and network
for each local network. Exchange this information with the network
administrators at each remote site.
• The Rendezvous secure daemon limits clients to communication on a set of
authorized network and service pairs.
• The current value cache, rvcache, accepts all three transport parameters.
When you configure this program, include any special values as needed.
• Many Rendezvous programs accept transport parameters on their command
lines. Inform all users of any special values that apply.

20
| Network Details
Service Selection
Rendezvous daemon (rvd) processes communicate using UDP or PGM services.

The service parameter instructs the Rendezvous daemon to use this service
whenever it does network communications on behalf of this transport.
As a direct result, services divide the network into logical partitions. Each
transport communicates over a single service; a transport can communicate only
with other transports on the same service. To communicate with more than one
service, a program must create more than one transport.
Interaction between Service and Network Parameters

Within each Rendezvous daemon, all the transports that use a specific service
must also use the same network parameter. That is, if the service parameters
resolve to the same UDP or PGM port, then the network parameter must also be
identical. (This restriction extends also to routing daemons.)
For example, suppose that the program foo, on the computer named orange, has
a transport that communicates on the service svc1 over the network lan1. It is
illegal for any program to subsequently create a transport to that rvd on orange to
communicate on svc1 over any other network—such as lan2. Once rvd binds
svc1 to lan1, that service cannot send outbound broadcast messages to any other
network. Attempting to illegally rebind a service to a new network fails; the
transport creation call produces the status code TIBRV_INIT_FAILURE.
To work around this limitation, use a separate service for each network.
The limitation is not as severe as it might seem at first, because it only affects
outbound broadcast messages.
• Point-to-point messages on the transport’s service travel on the appropriate
network (as determined by the operating system) irrespective of the
transport’s network parameter.
• Inbound broadcast messages on the transport’s service can arrive from any
network, irrespective of the transport’s network parameter.

Service Selection 21
|
Specifying the UDP or PGM Service

Programs can specify the service in one of several ways, listed in order of
preference in Table 1.
Table 1 Specify UDP or PGM Service (Sheet 1 of 2)
Port number When a program specifies a UDP or PGM port number, it must be a
string representing a decimal integer. For example:
"7890"
Service name When a program specifies a service name, the transport creation function
searches the network database using getservbyname(), which searches
a network database such as NIS, DNS or a flat file such as
/etc/services (in some versions of UNIX).
Default If a program does not specify a service, or it specifies null, the transport
creation function searches for the service name rendezvous.
(Non-Secure Daemons)
If getservbyname() does not find rendezvous, the Rendezvous daemon
instructs the transport creation function to use a hard default:
• The TRDP daemon offers the default service 7500.
• The PGM daemon offers the default service 7550.
We strongly recommend that administrators define rendezvous as a

service, especially if either the of ports 7500 or 7550 is already in use.
For example, network administrators might add the following service
entry to the network database (where 7500 is the port number):
rendezvous 7500/udp
Once this entry is in the network database, programmers can

conveniently specify NULL or the empty string as the service argument
to create a transport that uses the default Rendezvous service.
Default Secure daemons use internal defaults, which must be set explicitly by the
administrator; see Default Network and Service on page 154.
(Secure Daemons)

22
| Network Details
Table 1 Specify UDP or PGM Service (Sheet 2 of 2)
Direct Communication To enable direct communication, specify two parts separated by a colon:
• UDP or PGM service for regular communication
• UDP service for direct communication (RPTP)
You may specify both parts either as a service name or a port number.
Direct communication is not available when connecting to a remote
daemon.
For a general overview, see Direct Communication on page 116 in TIBCO
Rendezvous Concepts.
PGM and TRDP

The TRDP and PGM variants of rvd interpret the service specification differently:
• The TRDP variant interprets it as a UDP service.
• The PGM variant interprets it as a pair of services with the same port
number—a PGM service for multicast communication, and a UDP service for
point-to-point communication. Even though these twin services share the
same port number, data does not cross from one to the other.

Network Selection 23
|
Network Selection
Every network transport object communicates with other transport objects over a
network. On computers with only one network interface, the Rendezvous
daemon communicates on that network without further instruction from the
program.
On computers with more than one network interface, the network parameter
instructs the Rendezvous daemon to use a particular network for all
communications involving this transport. To communicate over more than one
network, a program must create a separate transport object for each network. For
further details, see Limitation on Computers with Multiple Network Interfaces on
page 25.
The network parameter also specifies multicast addressing details (for a brief
introduction, see Multicast Addressing on page 25).
To connect to a remote daemon, the network parameter must refer to the network
from the perspective of the remote computer that hosts the daemon process.
Constructing the Network Parameter

The network parameter consists of up to three parts, separated by semicolons—
network, multicast groups, send address—as in these examples:
"lan0" network only
"lan0;224.1.1.1" one multicast group
"lan0;224.1.1.1,224.1.1.5;224.1.1.6" two multicast groups, send address
"lan0;;224.1.1.6" no multicast group, send address
Part One—Network
Part one identifies the network, which you can specify in several ways:
Table 2 Specify Network (Sheet 1 of 2)
Host name When a program specifies a host name, the transport

creation function calls gethostbyname(), which
searches a network database to obtain the IP address.
Host IP address When a program specifies an IP address, it must be a

string representing a multi-part address. For example:
"101.120.115.111"

24
| Network Details
Table 2 Specify Network (Sheet 2 of 2)
Network name When an application specifies a network name, the

(where supported) transport creation function calls getnetbyname(),
which searches a network database such as Network
Information Services (NIS) or a flat file (such as
networks) in the system directory.
Network IP number If a program specifies a host IP address or a network IP

number it must be in dotted-decimal notation. For
example, 101.55.
Interface name When an application specifies an interface name, the

(where supported) transport creation function searches the interface table
for the specified interface name. For example, lan0.
The interface name must be one that is known to
ifconfig or netstat.
Default If a program does not specify a network, the transport

creation function uses the default network interface:
(Non-Secure
Daemons) • TRDP daemons use the network interface which
corresponds to the host name of the system as
determined by the C function gethostname().
• PGM daemons use the default PGM multicast
interface, 224.0.1.78.
Default Secure daemons use internal defaults, which must be

set explicitly by the administrator; see Default Network
(Secure Daemons)
and Service on page 154.
The use of the UDP broadcast protocol has generally been superseded by the IP
multicast protocol. To use broadcast protocols without multicast addressing,
specify only part one of the network parameter, and omit the remaining parts.
Part Two—Multicast Groups

Part two is a list of zero or more multicast groups to join, specified as IP
addresses, separated by commas. Each address in part two must denote a valid
multicast address. Joining a multicast group enables listeners on the resulting
transport to receive data sent to that multicast group.
For a brief introduction to multicasting, see Multicast Addressing on page 25.

|
Part Three—Send Address

Part three is a single send address. When a program sends broadcast data on the
resulting transport, it is sent to this address. (Point-to-point data is not affected.) If
present, this item must be an IP address—not a host name or network name. The
send address need not be among the list of multicast groups joined in part two.
If you join one or more multicast groups in part two, but do not specify a send
address in part three, the send address defaults to the first multicast group listed
in part two.
Multicast Addressing
Multicast addressing is a focused broadcast capability implemented at the
operating system level. In the same way that the Rendezvous daemon filters out
unwanted messages based on service groups, multicast hardware and operating
system features filter out unwanted messages based on multicast addresses.
When no broadcast messages are present on the service, multicast filtering
(implemented in network interface hardware) can be more efficient than service
group filtering (implemented in software). However, transports that specify
multicast addressing still receive broadcast messages, so combining broadcast
and multicast traffic on the same service can defeat the efficiency gain of multicast
addressing.
Rendezvous software supports multicast addressing only when the operating
system supports it. If the operating system does not support it, and you specify a
multicast address in the network argument, then transport creation calls produce
an error status (TIBRV_NETWORK_NOT_FOUND).
Limitation on Computers with Multiple Network Interfaces

On computers with more than one network interface, Rendezvous programs must
not attempt to combine communications over different network interfaces using
the same UDP or PGM service. To understand this limitation, consider these
examples of incorrect usage in the context of multiple network interfaces.
Erroneous Examples
• A program, mylistener, creates a transport using service 7500 and network
lan0; it listens to broadcast subjects using that transport. Other program
processes on both lan0 and lan1 send broadcast messages using service 7500.
As a result, mylistener might unexpectedly receive inbound messages from
lan1.

26
| Network Details
• An administrator configures the Rendezvous routing daemon on a computer

with two network interfaces (lan0 and lan1) using service 7500. Since the
administrator does not specify a -network parameter, the routing daemon
uses the default network interface.
As a result, the routing daemon forwards messages from its neighbor only to
the default network interface; however, it might forward messages from both
lan0 and lan1 to its neighbor.
• A program creates two network transports. Both use service 7500, but one
uses network lan0, while the other uses network lan1.
As a result, the call to create the second transport produces an error.
• Two programs on the same computer each create a transport. Both use service
7500, but one uses network lan0, while the other uses network lan1. Even
though these transports are in different processes, both transports connect to
the same Rendezvous daemon—which is subject to the limitation.
As a result, the program fails to create the second transport.
We recommend caution when you deploy Rendezvous programs or Rendezvous

routing daemons on any computer with multiple network interfaces.
Source of the Limitation

The roots of this limitation are in the underlying IP broadcast protocols. Consider
this asymmetry:
• When sending an outbound broadcast packet, IP software sends the packet on
exactly one network.
Rendezvous programs can specify this network with the transport creation
function’s network parameter.
• In contrast, IP software collects inbound broadcast packets from all network
interfaces.
Furthermore, when IP software presents an inbound packet to a client
program (such as rvd) it does not include any indication of the network on
which that packet arrived.
Because of this asymmetry, the actual behavior of IP broadcast protocols can be
different than one might expect.
Avoiding the Limitation

You can use two strategies to avoid problems associated with this limitation:
• Use a separate service for Rendezvous messages on each network.

|
• Use multicast addressing to precisely define a range of reachable transports.
Using a separate service can rectify all four of the erroneous examples. Multicast
addressing can rectify the first two erroneous examples, but not the latter two. In
all four examples, a single Rendezvous daemon is sufficient.
For example, consider these two approaches to rectifying the first erroneous
example:
• Separate Service
A program, mylistener, creates a transport using service 7500 and network
lan0; it listens to broadcast subjects using that transport. Other processes on
lan0 send messages using service 7500, but all processes on lan1 send
messages using service 7510. Separating by service prevents the transport
from receiving interference from lan1.
• Multicast Addressing
A program, mylistener, creates a transport using service 7500 and multicast
network lan0;224.1.1.1. This transport selectively receives only those
inbound multicast messages that are sent on network lan0, to multicast
address 224.1.1.1, on service 7500. Multicast addressing (where available)
filters out messages sent on other networks using any other multicast address.
However, multicast addressing does not filter out IP broadcast messages sent
on the same UDP service. Once again, the roots of this limitation are in the
underlying IP broadcast protocols.

28
| Network Details
Daemon Client Socket—Establishing Connections
The Rendezvous daemon (rvd) and the Rendezvous routing daemon (rvrd) both
open a client socket to establish communication with their clients (Rendezvous
programs). The -listen option to rvd and rvrd lets you specify where the
daemon should listen for new client connections. Conversely, Rendezvous
programs request connections with the daemon at that client socket. The daemon
parameter of the transport creation function determines how and where to find
the Rendezvous daemon and establish communication.
Each transport object establishes a communication conduit with a Rendezvous
daemon, as described in these steps:
1. The daemon process opens a (TCP) client socket, and waits for a client to
request a connection.
The -listen option of the Rendezvous daemon specifies where the daemon
listens for new client transports.
2. The program calls the transport creation function, which contacts the daemon
at the client socket specified in its daemon parameter.
The daemon parameter of the transport creation function must correspond to
the -listen option of the daemon process; that is, they must specify the same
communication type and socket number.
If no daemon process is listening on the specified client socket, then the
transport creation call automatically starts a new daemon process (which
listens on the specified client socket) and then attempts to connect to it.
3. The daemon process opens a conduit for private communication with the new
transport. All future communication uses that private conduit.
The request socket is now free for additional requests from other client
transports.
Specifying a Local Daemon

Specify the daemon’s client socket as a character string.
For local daemons, specify a TCP socket number; for example: "6555"
If you omit the daemon parameter of the transport creation function (in C, supply
NULL), it uses 7500 as the default. Similarly, to start a daemon process using the
default socket, omit the -listen option to the daemon command line.

Daemon Client Socket—Establishing Connections 29
|
In all cases, the communication type and socket number in the daemon parameter
of the transport creation call must match those given to rvd through its -listen
parameter.
Remote Daemon
In most cases, programs use a local daemon, running on the same host as the
program. Certain situations require a remote daemon, for example:
• The program runs on a laptop computer that is not directly connected to the
network. Instead, the laptop connects to a workstation on the network, and
the daemon runs on that workstation.
• The program connects to a network at a remote site.
For remote daemons, specify two parts (introducing the remote host name as the
first part):
• Remote host name.
• TCP socket number.
For example: "purple_host:6555".

Once again the communication type and socket number in the daemon parameter
of the transport creation call must match those given to rvd through its -listen
parameter. However, the -listen parameter still receives only a two-part
argument—without a remote host name.
Direct communication is not available when connecting to a remote daemon.

For a general overview, see Direct Communication on page 116 in TIBCO
Barring Remote Connections

A Rendezvous daemon or routing daemon can prohibit connections from remote
programs by specifying -listen "127.0.0.1". The special network address
127.0.0.1 represents the local host, so this parameter specifies that only local
programs may connect.
This configuration is especially important when a routing daemon runs on a
firewall computer.

30
| Network Details
Default Port and Service Numbers
For convenient reference, these tables list port and service numbers with special
meaning to Rendezvous components.
Rendezvous components use HTTP ports for browser administration interfaces.
Configurable daemons distributed with Rendezvous also open an ephemeral
HTTPS port (to keep the daemon configuration secure against unauthorized
modification). To find the actual HTTPS port that the operating system has
assigned, check the daemon’s start banner or log file. The configurable daemons
are rvrd, rvsd, rvsrd, rva and rvcache—but not rvd.
Table 3 Default HTTP Port Numbers
HTTP Port Rendezvous Component

Daemons Distributed with Rendezvous
7580 rvd, rvrd, rvsd, rvsrd
7581 rvcache
7680 rva
Daemons Distributed with Related Products
7880 rvacld
7590 rvtxd

Default Port and Service Numbers 31
|
Table 4 Default UDP or PGM Service Numbers
Service Description
rendezvous Program transport objects use these UDP or PGM services
7500 (TRDP) as defaults.
7550 (PGM) The component programs rva and rvrad follow this
convention.
For more detail, see Specifying the UDP or PGM Service
on page 21.
rendezvous-ft Fault tolerance members use these UDP or PGM services

7504 as defaults for fault-tolerance protocol communications.
Table 5 Default TCP Port Numbers
TCP Port Rendezvous Component

7500 rvd and rvrd use this TCP port as the default to listen for new
connections from program transports.
Program transport objects use this TCP port as the default to
establish connections to rvd or rvrd.
The component programs rva and rvrad follow this convention.
7600 rva uses this TCP port as the default to listen for new
connections from Java applets. See Listen Port on page 173.
TibrvRvaTransport objects in Java applets use this TCP port as
the default to establish connections with rva.

32
| Network Details
Disabling Multicast
When the command line for any of the daemon components includes
-no-multicast, the daemon disables multicast (and broadcast) communication.
This section describes the behavior of the daemons (rvd, rvrd, rvsd, rvsrd) when
multicasting is disabled.
API All changes in behavior occur with the daemon. These behavior changes are
transparent to Rendezvous API calls. Client programs can create transports that
specify multicast addressing or PGM service, send messages to any subjects, and
listen to any subjects. No changes to client programs are required.
Daemon Behavior Disabling multicast communication changes daemon behavior in these ways:
• When a client sends a message to a public subject, the daemon does not
multicast it (nor broadcast it) to the network.
• When a routing daemon receives multicast or broadcast messages from the
network, it does not forward them to other daemons within the local network.
When multicast communication is disabled, daemons continue to operate in these

ways:
• Point-to-point messages continue to flow in both directions between clients
and the network.
• All messages (including public subjects) flow among all the local clients of the
daemon.
For example, in Figure 1 on page 33, even though they connect to a daemon
that has disabled multicast, clients A, B and C can still exchange public
subjects among themselves. However, they can exchange only point-to-point
messages with D, E and F (clients of another daemon).
• All messages (including public subjects) flow in both directions between local
clients of a routing daemon and the daemon’s neighbors.
For example, in Figure 2 on page 33, J and K are local clients of a routing
daemon that has disabled multicast. Nonetheless, they can exchange public
subjects with transports on net Z. In contrast, L (a client of another daemon on
the same network cannot exchange public subjects with transports on net Z,
nor with J and K on net Y. (All clients on nets Y and Z can exchange
point-to-point messages.)
For another example, see rvsrd on page 129.

Disabling Multicast 33
|
Figure 1 Disabling Multicast: Public Subjects Still Flow Among Local Clients
Client Client Client Client Client Client

A B C D E F
rvd
rvd
-no-multicast
No
multicast
Network
Figure 2 Disabling Multicast: Routing Daemons
Client Client
J K
rvrd
rvrd
-no-multicast
No
multicast
Net Y Net Z
rvd
Client
L

34
| Network Details

| 35
Chapter 4 Rendezvous Daemon (rvd)
The Rendezvous daemon (rvd) is the background process that supports all
Rendezvous communications. Distributed processes depend on it for reliable and
efficient network communication. All information that travels between and
among processes passes through a Rendezvous daemon when it enters or exits a
host computer.
The Rendezvous daemon fills these roles:
• Route messages to program processes.
• Deliver messages reliably.
• Filter subject-addressed messages.
• Shield programs from operating system idiosyncrasies, such as low-level
sockets and file descriptor limits.
The Rendezvous daemon process, rvd, starts automatically when needed, runs
continuously and may exit after a period of inactivity.
For further general information about the Rendezvous daemon and reliable
broadcast delivery, see The Rendezvous Daemon on page 55 in TIBCO Rendezvous
Concepts.
Topics
• rvd, page 36
• Reliability and Message Retention Time, page 41
• Log Destination, page 43
• Browser Administration Interface—rvd, page 45

36
| Rendezvous Daemon (rvd)
rvd
Command
Syntax rvd [-http [<ip_address>:]<http_port>]

[-no-http]
[-listen [<ip_address>:]<tcp_port>]
[-no-permanent]
[-no-lead-wc | -lead-wc]
[-no-multicast]
[-reliability <time>]
[-logfile <log_filename>]
[-log-rotate <size>]
[-log-config <config_log_filename>]
[-foreground]
Purpose The command rvd starts the Rendezvous daemon process. The Rendezvous
daemon is the network I/O handler for all Rendezvous programs on a computer.
Remarks Usually, the Rendezvous daemon (rvd) process starts automatically. When a
Rendezvous program creates a transport, Rendezvous software determines
whether a daemon is already listening for connections (as specified by the daemon
parameter). If so, the new transport connects to that daemon. If not, it
automatically starts a new daemon and connects to it.
However, when the daemon parameter of the transport creation call specifies a
remote daemon, the daemon does not start automatically—you must start it
manually on the remote computer.
The rvd command starts the Rendezvous daemon manually. You might do this to
specify optional parameters, or a start a daemon that will accept connections from
programs running on remote computers.
When started automatically by a client, rvd can also exit automatically. If rvd is
not connected to any valid client transports for 2 minutes, then rvd automatically
exits. However, when started manually, rvd does not exit automatically. To
override this behavior, start it manually with the -no-permanent option.
The Rendezvous routing daemon (rvrd) subsumes the behavior of rvd, so it is
usually not necessary to run rvd on computers that already run rvrd.
Running duplicate daemons on one computer yields no benefit, and can cause
errors or decreased efficiency.
Licenses To put new licenses into effect, stop and restart rvd. Restarting rvd can be manual
or automatic as described above.

rvd 37
|
The first time a program transport successfully connects to the Rendezvous

daemon process, rvd starts the clock ticking against license tickets. When a license
expires, all programs receive an advisory message, and rvd stops delivering
messages.
Command Line Parameters
(Sheet 1 of 4)
Parameter Description
-http <ip_address>:<http_port> The browser administration interface accepts connections on
this HTTP port. Permit administration access only through the
-http <http_port>
network interface specified by this IP address.
To limit access to a browser on the rvd host computer, specify
127.0.0.1 (the local host address).
When the IP address is absent, the daemon accepts

connections through any network interface on the specified
HTTP port.
If the explicitly specified port is already occupied, the program
exits.
When this parameter is entirely absent, the default behavior is
to accept connections from any computer on HTTP port 7580.
If this default port is unavailable, the operating system assigns
an ephemeral port number.
In all cases, the program prints the actual HTTP port where it
accepts connections.
-no-http Disable all HTTP connections, overriding -http.

38
(Sheet 2 of 4)
-listen <ip_address>:<tcp_port> rvd (and by extension, rvrd operating within the local
network) opens a TCP client socket to establish
-listen <tcp_port>
communication between itself and its client programs. The
-listen parameter specifies the TCP port where the
Rendezvous daemon listens for connection requests from
client programs. This -listen parameter of rvd corresponds
to the daemon parameter of the transport creation call (they
must specify the same TCP port number).
The IP address specifies the network interface through which
this daemon accepts TCP connections.
To bar connections from remote programs, specify IP address
127.0.0.1 (the loopback interface).

connections from any computer on the specified TCP port.
to accept connections from any computer on TCP port 7500.
For more detail about the choreography that establishes
conduits, see Daemon Client Socket—Establishing
Connections on page 28.
This parameter does not correspond to the service parameter

of the transport creation call—but rather to the daemon
parameter.
-no-permanent If present (or when rvd starts automatically), rvd exits after 2
minutes during which no transports are connected to it.
If not present, rvd runs indefinitely until terminated.
This flag is deprecated in release 7.0 and later. To preserve

backward compatibility with existing scripts, rvd ignores this
flag, rather than rejecting it.
-permanent

rvd 39
|
(Sheet 3 of 4)
-no-lead-wc | Sending to subjects with lead wildcards (for example, > or
-lead-wc *.foo) can cause unexpected behavior in some applications,
and cause network instability in some configurations. This
option lets you selectively screen wildcard sending.
When -no-lead-wc is present, rvd quietly rejects client
requests to send outbound messages to subjects that contain
wildcards in the lead element. rvd does not report excluded
messages as errors.
When -lead-wc is present (or when neither flag is present),
rvdallows sending messages to subjects with lead wildcards.
-no-multicast When present, the daemon disables multicast (and broadcast)

communication. For details, see Disabling Multicast on
page 32.
-reliability <time> Rendezvous daemons compensate for brief network failures

by retaining outbound messages, and retransmitting them
upon request.
If this parameter is absent, the default retention time is 60
seconds. In rare situations, shorter times are appropriate. We
strongly discourage increasing the retention time beyond 60
seconds (see Reliability and Message Retention Time on
page 41).
If this parameter is present, rvd (and by extension, rvrd
operating within the local network) retains messages for <time>
(in seconds).
For more information see Reliability and Message Retention
Time on page 41.
-logfile <log_filename> Send log output to this file.

When absent, the default is stderr.
-log-rotate <size> When present, activate the log rotation regimen (see Log
Rotation on page 43), limiting the combined total size of the 10
log files to this size (in kilobytes).
When you specify this option, you must also specify
-logfile.
When absent, do not rotate log files.

40
(Sheet 4 of 4)
-log-config <config_log_filename> Send duplicate log output to this file for log items that record
configuration changes. The daemon never rotates nor removes
this special log file. Instead, this file remains as a record of all
configuration changes.
-foreground Available only on UNIX platforms.

When present, rvd runs as a foreground process.
When absent, rvd runs as a background process.

Reliability and Message Retention Time 41
|
Reliability and Message Retention Time
The -reliability parameter to Rendezvous daemon processes (rvd and rvrd)

specifies the time for which the daemon retains outbound messages. Retaining
message data allows the daemon to retransmit message packets upon request
from another daemon process (which did not correctly receive the data).
The default retention time is 60 seconds. In most situations, this default is
sufficient for reliability and does not impose high memory requirements on the
daemon process.
However, in some situations a shorter retention time can be beneficial, because it
decreases memory requirements. For example:
• High-Speed Sender
Consider a program that sends messages at very high data rates. Using the
default reliability retention time, the daemon must retain 60 seconds worth of
data in its process memory; this volume of data might overwhelm the host
computer’s available memory. To reduce the rvd process memory
requirement, consider shortening the retention time.
• Time-Sensitive Data
In some programs, data becomes obsolete before 60 seconds elapse. For
example, in real-time multi-player game networks, data might become
obsolete in less than one second. Retaining and retransmitting obsolete data
burdens the daemons and the network without any benefit. Shortening the
retention time can improve overall performance.
In some situations, it is not unreasonable to reduce retention time to zero.
Decreasing retention time decreases reliability, and increases the probability of
lost data. DATALOSS advisory messages indicate message data lost because the
sending daemon no longer retains it.
We strongly discourage increasing the retention time beyond 60 seconds. Longer
retention times can increase memory requirements and decrease overall
performance. If greater reliability is required, consider using certified delivery
features instead (see Certified Message Delivery on page 139).
It is not necessary that all daemons in a network use the same retention time.
The -reliability parameter affects only the messages that flow outbound from a
daemon to the local network; it does not affect inbound messages from the
network. It does not affect the operation of rvrd as it transfers messages across
network boundaries.

42
See Also For additional background information, see also Reliable Message Delivery on
page 58.

Log Destination 43
|
Log Destination
Each Rendezvous daemon and component process—rvd, rvrd, rvsd, rvsrd, rva,
rvtrace—produces log output. The content of log output varies, but the
semantics of command line options that affect logging are identical for all of these
components:
• When all of the command line options that affect logging are absent, daemons
send log output to stdoutstderr.
• When -logfile <log_filename> is present, daemons send log output to the file
you specify, namely <log_filename>.
• When -log-rotate <size> is also present, daemons use a log rotation
regimen. For details, see Log Rotation below.
• When -log-config <config_log_filename> is present, daemons log duplicate
copies of configuration changes to the file you specify, namely
<config_log_filename>. Daemons never rotate nor remove this file, so a
permanent record of this important information remains. (This parameter is
available only for daemons.)
Log Rotation
The command line option -log-rotate <size> limits the growth of log files. The
<size> parameter specifies the maximum disk space (in kilobytes) that log files can
occupy (approximately).
When -log-rotate is present, the daemon establishes as sequence of up to ten
log files, limiting each file to approximately one tenth of the maximum <size>. The
daemon rotates the log files according to this renaming plan:
• The first file is <log_filename> (the argument to -logfile)—for example,
rvd.log (without any suffix digit). This name also becomes the base for a
sequence of subsequent files.
• When rvd.log reaches its limit, the daemon rotates log files:
— It closes rvd.log.
— It appends the next available suffix digit to the base name, and opens a file
with that name as the new current file. Suffix digits follow the sequence
none, 1, 2, 3, 4, 5, 6, 7, 8, 9, then back to none (so the tenth rotation returns
to the original base name).
• If the first log file already contains old log items, the daemon appends the new
items to the end of the file (preserving the old logs).

44
For all subsequent rotations (that is, after the first file) the daemon deletes any
existing file before opening a new file and writing log items to it.
• When the daemon terminates and restarts, the rotation state is reset.
You can determine the most recent file by comparing either packet time
stamps within the files, or file modification times.
Current Log Page

The browser interfaces for all daemon components include a Current Log page,
which displays the most recent 4 kilobytes of log output (for convenience).

Browser Administration Interface—rvd 45
|
Browser Administration Interface—rvd
The browser administration interface lets you control rvd from a web browser.
Although rvd does not have any configurable operating parameters, you can
view internal data structures that reflect network conditions.
Topics
• Navigation, page 46
• General Information, page 48
• Clients, page 50
• Services, page 52

46
Navigation
All browser administration interface pages display a navigation panel at the left
side of the page. Use these links to display other pages.
Figure 3 rvd Navigation Panel
(Sheet 1 of 2)
Category Item Description

State General This page displays information about an rvd process; see
Information General Information on page 48.
Clients This page summarizes the client transports; see Clients on

page 50.
Services This page summarizes network services activity; see Services

on page 52.

Navigation 47
|
(Sheet 2 of 2)

Miscellaneous Current Log This page displays the most recent 4 kilobytes from the log file.
TIBCO The product page from the TIBCO web site.

Rendezvous
Web Page
Copyright The Rendezvous copyright page.

48
General Information
rvd(like all Rendezvous components) displays information about itself on this

page.
To display this page, click General Information in the left margin of any page of
the rvd browser administration interface.
Figure 4 rvd General Information Page
(Sheet 1 of 2)
Item Description
component The name of the program—rvd (or rvsd).
version Version number of the program.
license ticket The license ticket that validates this process.
host name The hostname of the computer where the daemon process runs.
Notice that the daemon process can run on one computer, while you access its
browser interface from another computer.
user name The user who started the daemon process.
IP address The IP address of the computer where the daemon process runs.
client port The TCP port where the daemon listens for client connections.
network The number of network services on which this daemon’s clients communicate.
services

General Information 49
|
(Sheet 2 of 2)
Item Description
process ID The operating system’s process ID number for the component.

50
Clients
rvd displays information about its clients on this page.

To display this page, click Clients in the left margin of any page of the rvd
browser administration interface.
Figure 5 rvd Clients Page
Item Description
table rows Each row of the table describes one client transport.
Description The description string of the transport object. Client programs set this string using
an API call.
User The user name of the user that started the client program process.
Service The UDP or PGM service on which the client transport communicates.
Identifier A globally unique identifier for the transport object. Click this identifier to view
Client Detail page.
Client Detail
This page displays additional detail about a particular client transport.
To display this page, click any transport identifier in the Clients page.

Clients 51
|
Figure 6 rvd Client Detail Page
Item Description
Description The description string of the transport object. Client programs set this string using
an API call.
User The user name string of the user that started the client program process.
Service The UDP or PGM service on which the client transport communicates.
Serial Serial number of the Rendezvous license ticket that validates this client connection.
Number
Expiration Expiration date of the Rendezvous license ticket.
Identifier A globally unique identifier for the transport object.
Version Version number of the Rendezvous API library that this client uses.
Subscription This table lists the subscriptions that this transport has registered with rvd. Each
Information row displays the subject name of one subscription.
Limited to 50 subscriptions; if greater than 50, it displays only the approximate
number of subscriptions.

52
Services
On this page rvd displays information about the network services it mediates for
its clients.
To display this page, click Services in the left margin of any page of the rvd
Figure 7 rvd Services Page
Item Description
table rows Each row of the table describes one network service—that is, a UDP or PGM
service on a particular network interface.
Service The UDP or PGM service number. Click this number to view Service Detail page.
Network The network number.
Hosts The number of other host computers with Rendezvous daemons that communicate
on this network and service.
Clients The number of client transports that use this network and service.
Service Detail
This page displays additional detail about a particular network service.
To display this page, click any service number in the Services page.

Services 53
|
Figure 8 rvd Service Detail Page
(Sheet 1 of 3)
Item Description
Service The UDP or PGM service number.
Network The network number.
Reliability rvd retains outbound message data for retransmission. After this interval, it
discards the data. For complete details, see Reliability and Message Retention
Time on page 41.
Creation Date and time that this service became active.

54
(Sheet 2 of 3)
Item Description
Clients The number of client transports that use this network service. To view the Clients
page, click this item.
Hosts The number of other host computers with Rendezvous daemons that
communicate on this network and service. To view the Hosts page, click this
item.
Subscriptions The number of subscriptions registered with the daemon on this network service.
To view the list of subscriptions, click this item.
Inbound Rates The rate (per second) at which inbound messages, bytes and packets arrived on
this network service during the most recent sampling period.
Outbound The rate (per second) at which the daemon sent outbound messages, bytes and
Rates packets on this network service during the most recent sampling period.
Information This panel displays the 50 most recent DATALOSS advisories.

Alerts
Inbound Totals Cumulative statistics about inbound data; running totals since the start of the
daemon process:
• msgs—number of messages
• bytes—number of bytes
• pkts—number of packets
• missed—number of missed packets (detected as a packet sequence gap)
• lost MC—number of multicast packets lost because the sending daemon
could not retransmit them
• lost PTP—number of point-to-point packets lost because the sending daemon
could not retransmit them

Services 55
|
(Sheet 3 of 3)
Item Description
Outbound Cumulative statistics about outbound data; running totals since the start of the
Totals daemon process:
• msgs—number of messages
• bytes—number of bytes
• pkts—number of packets
• retrans—number of packets retransmitted (multicast and point-to-point)
• lost MC—number of multicast packets the daemon could not retransmit (too
old)
• lost PTP—number of point-to-point packets the daemon could not retransmit
(too old)
Hosts
This page displays Rendezvous daemon process instances on other host
computers that communicate on the same network and service. From this page,
you can view the service pages of those other daemons.
To display this page, click the word hosts in the Service Detail page.
This page lists any Rendezvous communications daemon host, whether the
process is rvd, rvsd, rvrd, or rvsrd.
Figure 9 rvd Hosts Page
(Sheet 1 of 2)
Item Description
host Each row of this table represents one Rendezvous daemon process and its host
computer.

56
(Sheet 2 of 2)
Item Description
Hostname The name of the computer where the other daemon is running.
IP Address The IP address of the computer where the other daemon is running.
Version The version of the Rendezvous daemon on the other host.
Serial The serial number of the license for that daemon.
Uptime The elapsed time that the daemon has been using the common UDP or PGM
service.

| 57
Chapter 5 Routing Daemon (rvrd)
Proper configuration of rvrd is one of the more complex administration tasks,

and it is critically important for enterprises that use Rendezvous routing
daemons. We recommend that network administrators give special attention to
this chapter.
Topics
• Routing Daemon Overview, page 59

• Concepts, page 60
• Requirements, page 62
• Restricting Message Flow, page 63
• rvrd Process, page 64
• Routing Table Entry, page 65
• Local Network, page 66
• Neighbors, page 69
• Adding Neighbor Interfaces, page 71
• Redundant Routing Daemons for Fault Tolerance, page 74
• Independent Routing Table Entries in One Process, page 77
• Common Topology Errors, page 82
• Security and Firewalls, page 85
• Connecting PGM and TRDP Networks with Routing Daemons, page 87
• Backlog Protection, page 88
• Idle, page 89
• Routing Daemon Logging, page 90
• rvrd, page 92

58
| Routing Daemon (rvrd)
• Browser Administration Interface—rvrd, page 96

Routing Daemon Overview 59
|
Routing Daemon Overview
Rendezvous daemons (rvd) deliver messages to programs on computers within a

single network. Delivering messages beyond network boundaries requires an
additional software component—Rendezvous routing daemons (rvrd).
Routing daemons efficiently connect Rendezvous programs on separate IP
networks, so that messages flow between them as if on a single network.
Communicating programs remain decoupled from internetwork addresses and
other details.
The routing daemons forward Rendezvous messages between networks. When
routing daemons are present, Rendezvous programs on one network can listen
for subject names and receive messages from other networks transparently—
neither the sending nor the receiving programs require any code changes.
Administrators retain control over the subject names that can flow in or out of
each network.
Situations
Use the routing daemon in situations where one or more of these conditions apply:
• Participating networks lie in distant geographic areas.
• Participating networks lie in nearby geographic areas, but are not connected
by multicast routing hardware.
• Participating networks are separated by a firewall.
• Messages must traverse expensive or slow WAN links.
Subsumes Rendezvous Daemon

In addition to routing Rendezvous messages to and from other networks, a
routing daemon process also serves its host computer as a Rendezvous daemon
(rvd). It is not necessary to run a separate rvd on a computer that is already
running an rvrd process.

60
Concepts
This section compares routing daemon software to a hardware router, using an

extended analogy to introduce the operational concepts of Rendezvous routing
daemons.
Goal
The goal of routing daemon software is to take Rendezvous messages from one
network, and make them available on other networks. The effect is to connect a
set of networks into a larger network.
Compare this goal to the goal of routing hardware—to take packets from one
network, and make them available on other networks. Once again, the effect is to
connect a set of networks into a larger network.
Connections
Routing daemon software uses a routing table to define connections to local
networks, and to other routing daemons.
Compare this tool to a hardware router, which uses a routing table to define the
connections between the router and its interfaces.
Each entry in the routing table describes one routing daemon and its connections.
Although each routing daemon specifies only its own routing table entry, all the
routing daemons in a WAN cooperate to share this information, so that every
routing daemon builds a copy of the complete global routing table.
Local Network
A routing daemon serves a set of local networks by forwarding messages between
those networks and other networks (usually, by way of other routing daemons).
While routing hardware specifies its local networks primarily in terms of network
interfaces, routing daemon software specifies each local network as a pair
combining network and UDP or PGM service. UDP or PGM services effectively
divide the physical network into separate logical networks—even though they
use the same hardware.

Concepts 61
|
A routing daemon filters messages by subject name, restricting the subjects that
its local networks can import and export. Filtering messages by subject in routing
daemon software yields a finer granularity of control than filtering packets in a
hardware router. Routing daemons control the set of subjects that each network
can export to other networks, and import from other networks. For more
information, see Subject Gating on page 66.
Neighbor
To achieve the goal of forwarding message between networks, routing daemons
connect to other routing daemons. A routing daemon declares its potential
neighbors—the other routing daemons to which it can directly connect.
Two potential neighbors become actual neighbors when they establish a TCP
connection.
Figure 10 Routing Daemons
Legend Net X.foo.com Net Y.foo.com

UDP 7102 UDP 3355
Local Network
Neighbor Link
Routing Daemon
Route
The set of connections through which a message travels between its originating
network and its destination network is called a route. Several potential routes can
exist between the originating and destination networks; routing daemons select
the actual route for each message.

62
Requirements
These four conditions enable delivery of Rendezvous messages between

networks:
Routing Daemons
A routing daemon must exist on at least one computer of each local network that
participates by sending or receiving Rendezvous messages.
Neighbor Connections
The network administrator must allow the routing daemons to establish TCP or
SSL connections, so the routing daemons can become neighbors.
Subject Gating
Each routing daemon must export the relevant subject names from its local
network, and import the relevant subject names from other networks.
For details, see Subject Gating on page 66, and Subject Filtering with Wildcards on
page 67.
Subject Interest
Import and export gating is not sufficient to start the flow of messages. To receive
forwarded messages, programs within the local network must express interest in
the relevant subject names, by listening for those subjects.
Whenever a routing daemon detects interest in a subject within one of its local
networks, it cooperates with other routing daemons to forward that subject to that
local network. When programs in the network no longer retain interest in a
subject, the routing daemons stop forwarding it.
For more details, see Routing Daemons Filter Interest to Permitted Subjects on
page 68.

Restricting Message Flow 63
|
Restricting Message Flow
Routing daemons can be very selective in allowing messages to flow between

networks. Network administrators can use this selectivity in several important
ways:
• Restrict sensitive information to particular networks.
• Limit the volume of messages between networks.
• Constrain information to flow in only one direction between two networks.
Restricting Messages by Service or Port

For coarse-grained control over information flow, limit communication between
networks to particular UDP or PGM services.
Recall that Rendezvous programs can segregate messages by specifying the
service parameter to the transport creation function. The UDP or PGM service is
part of the definition of a local network; the routing daemon exchanges with its
neighbors only information that arrives on the designated service.
For example, if your organization adopts a convention to send sensitive
information via particular UDP or PGM services, then you can use the routing
daemon to regulate (or even completely disable) the import and export of
messages sent via those services.
Restricting Messages by Subject Name

For fine-grained control over all the information flowing in or out of your
networks, limit communication by subject name.
Subject names specify exactly which messages may enter and leave a local
network—the routing daemon blocks all other Rendezvous messages. For details,
see Subject Gating on page 66.

64
rvrd Process
Initial State
In its initial state an rvrd process operates identically to an rvd process; it does
not route messages yet.
Administrators use the browser administration interface to configure the routing
daemon, and to start its operation as a software router.
Administration File
An rvrd process can store its routing table entry and parameters in a file. When
the process restarts, it can read that file to resume its previous operating
configuration.
The administration file is stored in a format that is not human-readable. To
examine or change the routing table entry or parameters, use the browser
administration interface.
HTTP Administration Interface

You can configure rvrd using the browser administration interface. For more
information, see Browser Administration Interface—rvrd on page 96, and the
command line parameter -http for rvrd on page 92.
Logging
An rvrd process can output a log of its activity. For details, see Routing Daemon
Logging on page 90.
Routing Table Entry

Each rvrd process specifies its routing table entry. For details, see Routing Table
Entry on page 65.

Routing Table Entry 65
|
Routing Table Entry
Routing table entries are the basic building blocks of a Rendezvous routing
system. In most situations, each routing daemon process embodies a single
routing table entry, which denotes that daemon throughout the WAN, and
describes its operation.
In rare situations one routing daemon process can embody several routing table
entries. Each entry defines a separate and independent software router, but
without the cost associated with process switching. For more information, see
Independent Routing Table Entries in One Process on page 77.
Combining all the routing table entries of all the routing daemons produces the
global routing table. Each routing daemon uses its copy of the global routing table
to forward messages efficiently to other routing daemons and their networks.
Router Name
Each routing table entry has a name. Routing daemons use these names to
identify one another—so names must be unique throughout the entire WAN.
One convenient way to ensure unique names is to use the fully-qualified DNS
names of the rvrd host computers; for example, frobitz.yellowNet.baz.com.
(When one process embodies several routing table entries, you can use a prefix to
create unique names; for example, 1.frobitz.yellowNet.baz.com).
Other naming conventions are acceptable, as long as the names are unique.
The name is a string of alphanumeric, dot, and dash characters. The maximum
total length of the string is 64 characters (including the dot separators).
Local Networks
Each routing daemon can serve zero or more local networks. For details, see Local
Network on page 66.
Notice that a routing daemon need not serve any local networks. In this
configuration, it operates as a way station, forwarding message traffic between
other routing daemons—for example, to cross a firewall. For an illustration of this
role, see Security and Firewalls on page 85.
Neighbors
Each routing daemon can connect to zero or more neighbors (routing daemons on
other networks). For details, see Neighbors on page 69.

66
Local Network
Each routing daemon can serve zero or more local networks.
Network and Service

Two parameters together define the local network:
• UDP or PGM Service
For details, see Specifying the UDP or PGM Service on page 21.
• Network Specification
For details, see Constructing the Network Parameter on page 23.
Local Network Name

Each local network must have a globally unique network name.
One convenient way to generate globally unique network names is to concatenate
the UDP or PGM service, the network specification, and the DNS domain name.
For example, 7500.fooNet.baz.com could refer to a local network using service
7500; in contrast, the name 7522.fooNet.baz.com would refer to the local
network using service 7522 on the same physical network.
Although that naming scheme is convenient, it can sometimes adversely affect
network bandwidth use. Consider using shorter unique names in these situations:
• When WAN bandwidth is severely limited.
• When the average message is very small (smaller than 50 bytes).
Like router names, each local network name is a string of alphanumeric, dot, and
dash characters. The maximum total length of the string is 64 characters
(including the dot separators).
When several routing daemons serve one network, each routing daemon must
specify the same name for that network.
Subject Gating
The router configuration determines the set of public subjects that can potentially
pass between the routing daemon and the local network:

Local Network 67
|
• Export subjects can flow out from the local network to the routing daemon,
and from there to other networks.
• Import subjects can flow into the local network from the routing daemon.
Point-to-Point Gating
Routing daemons automatically transmit point-to-point messages as appropriate:
• When a routing daemon receives a point-to-point message whose destination
is elsewhere in the global routing table, it forwards that message to the routing
daemon that serves the destination network.
• When a routing daemon receives a point-to-point message whose destination
is in one of its local networks, it forwards that message directly to rvd on the
destination computer.
• Administrators do not need to explicitly import or export inbox subject
names.
Subject Filtering with Wildcards

The wildcard characters, * and >, have the same semantics in import, export and
exchange parameters as they do in listening calls:
• * matches any single element.
• > in the last (rightmost) position matches one or more trailing elements.
Recall that these rules of import parameter behavior apply to routing daemons,
and also to the Rendezvous agent (rva).
Table 6 Importing Wildcard Subjects (Sheet 1 of 2)
Importing this Matches messages with But not names like these
wildcard name names like these (reason)
FOO.* FOO.BAR FOO.BAR.BAZ (extra element)
FOO.> FOO.BAR FOO (missing element)

FOO.BAR.BAZ
FOO.BAR.BAZ.BOX
FOO.*.> FOO.BAR.BAZ FOO.BAR (missing element)

FOO.BAR.BAZ.BOX
FOO (missing elements)

68
Table 6 Importing Wildcard Subjects (Sheet 2 of 2)
Importing this Matches messages with But not names like these
wildcard name names like these (reason)
FOO.*.STOP FOO.BAR.STOP FOO.STOP (missing element)
FOO.FOZ.STOP
FOO.BAR.BAZ (unmatched
3rd element)
Routing Daemons Filter Interest to Permitted Subjects

Routing daemons filter local listening interest according to the subjects that the
local networks can import and export. The general rule is that routing daemons
disregard listening interest that would include subjects in either of these
categories:
• Subjects that the listener’s local network cannot import.
• Subjects that the sender’s local network cannot export.
For example, consider a situation in which the local network imports FOO.> (that
is, it does not permit any other subjects to enter from the WAN). When a process,
L1, within the local network listens to the subject > (that is, the wildcard that
matches any subject), the routing daemon first compares it to the permitted
import subjects; since > is not a subset of FOO.>, the routing daemon does not
forward any messages into the local network, so L1 does not receive any
messages.
When a second process, L2, in the same local network, listens to the subject
FOO.BAR, the routing daemon begins importing messages (because the subject
matches a subject for which import is permitted); both L1 and L2 receive the
imported messages.
When a third process, L3, listens to the subject FOO.>, the routing daemon widens
the set of messages it imports; both L1 and L3 receive the additional message
subjects.
See Also Using Wildcards to Receive Related Subjects on page 66 in TIBCO Rendezvous
Concepts
Fixed Subject Interest
The concept of fixed subject interest is obsolete in release 6 (and later). Instead,
subject interest dynamically determines the set of subjects that actually flow to
and from a network.

Neighbors 69
|
Neighbors
Neighbor links connect routing daemons. A routing daemon declares its potential
neighbors in its routing table entry. Two routing daemons become actual
neighbors when they establish a TCP connection.
To declare potential neighbors, see Neighbor Interfaces on page 117. To examine
actual neighbors, see Connected Neighbors on page 103.
Neighbor Pairs
Neighbors operate in pairs—one router at each end of a neighbor connection.
Administrators can specify the pairs in four ways; see Adding Neighbor
Interfaces on page 71.
Local Connection Information

These parameters specify the local end of a neighbor connection.
Local Host The default value denotes the host computer’s default interface. You may
override this default by specifying another network interface on the local host
computer—either as a resolvable hostname, or as the IP address of the interface.
Local Connect In each neighbor declaration, a routing daemon designates a TCP port number
Port where the routing daemon accepts connection requests from that neighbor.
When a routing daemon declares several neighbors, it can designate a unique
local connect port for each neighbor, or some of its neighbors can share a local
connect port.
However, when a routing daemon process operates several routing table entries,
the routing entries may not share any local connect ports.
Remote Connection Information

These parameters specify the remote end of a neighbor connection.
Remote Router In most situations, a routing daemon identifies a neighbor using its unique router
Name name (see Router Name on page 65).
(For a counterexample, see Seek Neighbor with Any Name on page 72.)

70
Remote Host Specify the location of a neighbor either as a resolvable hostname, or as the IP
address of the computer in a remote network where the neighboring daemon is
running.
Remote Connect The remote port is the TCP port number where the remote neighbor listens for a
Port connection request from this routing daemon.
This parameter must match the local connect port of a routing table entry within
the rvrd process on the neighboring host computer.
Remote Public When neighbors communicate using SSL, you must enter the public certificate of
Certificate the authorized neighbor. For background information, see Certificates and
Security on page 53 in TIBCO Rendezvous Concepts.
Network Administration
Neighboring routing daemon processes must be able to establish a TCP
connection. The network administrator (at each site) must configure the hardware
(or software) routers and firewalls to permit this TCP connection between the two
routing daemon host computers.
Data Compression
Routing daemons can compress data to reduce the network volume that travels
between neighbors.
• Compression is most useful when you pay for WAN transmission by volume.
• Compression reduces volume at the cost of speed. Compression and
decompression slows rvrd processing at both ends of a neighbor link.
To enable data compression, select an appropriate option on the neighbor

interface forms of both neighbors; see Add New Neighbor Interface on page 119.

Adding Neighbor Interfaces 71
|
Adding Neighbor Interfaces
Routing daemons can declare neighbors in four ways:

• Active Neighbor, page 71
• Passive Neighbor, page 71
• Accept Any as Neighbor, page 72
• Seek Neighbor with Any Name, page 72
To specify a potential neighbor connection, see Add New Neighbor Interface on

page 119.
Active Neighbor
A routing daemon can declare another routing daemon as its neighbor, and
actively initiate a connection to it. If the connection is broken, the routing daemon
actively attempts to restore it.
Consider an example situation in which a routing daemons link several networks
within an enterprise. Each routing daemon within the enterprise declares every
other routing daemon as an active neighbor.
To specify an active neighbor, you must supply this information:

• Remote Router Name
• Remote Host
• Remote Connect Port
• Local Connect Port
Passive Neighbor
A routing daemon can declare that it passively accepts connections from its
neighbor, but does not actively initiate the connection itself.
Consider these example situations:
• Unidirectional firewall.
Routing daemon abc.homeNet.myDom.com is located behind a firewall that
allows connection requests in only one direction—outward. Active connection
attempts by its neighbor, mno.lyonNet.myDom.com, would invariably fail,
marking each attempt as a potential security violation at the firewall. When

72
mno.lyonNet.myDom.com declares abc.homeNet.myDom.com as a neighbor, it

can specify passive connect, reflecting its inability to initiate a connection to
abc.homeNet.myDom.com. To become actual neighbors,
abc.homeNet.myDom.com must initiate the connection to
mno.lyonNet.myDom.com.
• Modem restriction.
Routing daemon fgh.oshkoshNet.myDom.com is located on a host that
depends on a modem for network access; the modem settings permit
fgh.oshkoshNet.myDom.com to dial out, but the modem does not accept
incoming calls. Active connection attempts by its neighbor,
klm.chicagoNet.myDom.com, would invariably fail, while wasting resources.
When klm.chicagoNet.myDom.com declares fgh.oshkoshNet.myDom.com as
a neighbor, it can specify passive connect, reflecting its inability to initiate a
connection to fgh.oshkoshNet.myDom.com. To become actual neighbors,
fgh.oshkoshNet.myDom.com must initiate the connection to
klm.chicagoNet.myDom.com.
Specifying To specify a passive neighbor, you must supply this information:

Passive
• Remote Router Name
Neighbors
• Local Connect Port
Accept Any as Neighbor

Instead of declaring a specific set of neighbors, a routing daemon can declare that
it accepts neighbor connections from any routing daemon.
This configuration is especially useful for hub topologies, dial-in connections, and
any situation in which a routing daemon might operate with a large number of
potential neighbors.
Specify the local connect port where this routing daemon accepts TCP
connections from any (remote) routing daemon.
A routing daemon can simultaneously specify individual neighbors and declare
that it accepts any other routing daemons as neighbors.
Seek Neighbor with Any Name

Instead of declaring a neighbor with a specific name, a routing daemon can seek
out any available member from a set of routing daemons, without regard to its
name.

Adding Neighbor Interfaces 73
|
This configuration is especially useful for load balancing among a set of potential
neighbors with identical routes.
Specify the potential neighbors with two pieces of information:
• Remote Host, which must be either a DNS hostname that can resolve to more
than one IP address, or a virtual IP address.
• Remote Connect Port—all potential neighbors must listen for connection
requests on this port).
Each potential neighbor must accept connections from the seeking routing
daemon, without actively attempting to connect to it. The potential neighbors can
specify this in either of two ways:
• Accept connections from any neighbor, including the seeking routing daemon
(see Accept Any as Neighbor on page 72).
• Passively accept connections specifically from the seeking routing daemon
(see Passive Neighbor on page 71).

74
Redundant Routing Daemons for Fault Tolerance
Rendezvous routing daemons can cooperate for fault-tolerant service. Fault

tolerance protects routing daemons against hardware failures, process failures
and network segmentation.
In Figure 11, two routing daemon processes, E.Anet.moo.com and
F.Anet.moo.com, run on separate host computers, and serve the local client
network Anet.moo.com; similarly, routing daemons G.BNet.moo.com and
H.BNet.moo.com both serve local client network Bnet.moo.com. Neighbor links
connect E with G and H, and also F with G and H. Although these neighbor links
offer redundant paths from Anet to Bnet, the routing daemons cooperate to
forward each message only once. In failure situations, the routing daemons
automatically readjust to continue service smoothly.
Except for their router names, each pair of routing daemons specify identical
parameter configurations. For example, E.Anet.moo.com and F.ANet.moo.com
are exact duplicates of one another, except for their router names.
Notice that E and F are not neighbors, nor are G and H. It would be an error for
neighbors to serve the same local network (see Common Topology Errors on
page 82).
Figure 11 Fault Tolerance among Routing Daemons
Anet.moo.com
Legend
E.Anet.moo.com F.Anet.moo.com
Local Network
Neighbor Link
Routing Daemon Process
G.Bnet.moo.com H.Bnet.moo.com
Bnet.moo.com
Load Balancing
You can balance network load by directing messages along preferred routes.
Routing daemons let you specify preferred routes using two mechanisms:
• Path cost
• Subject import weight

Redundant Routing Daemons for Fault Tolerance 75
|
Path Cost You can specify the one-way path cost of each neighbor link. Routing protocols
seek the route with the lowest cost.
For example, Figure 12 repeats the fault-tolerant configuration from Figure 11—
however, the administrator has specified path costs on the neighbor links at G and
H. In particular, the outer links—G’s link to E, and H’s link to F—each specify a
cost of 1 (retaining the default cost). In contrast, the inner crossover links—G’s link
to F, and H’s link to E—each specify a cost of 5. When all the components operate
normally, messages flow across the lower cost links. When components fail,
messages flow across the lowest cost link that remains operational.
Figure 12 Path Cost and Subject Import Weight

Anet.moo.com
E.Anet.moo.com F.Anet.moo.com
1 5 5 1 Path Costs
G.Bnet.moo.com H.Bnet.moo.com
Import Weights: Import Weights:

foo.> 1 foo.> 10
bar.> 10 bar.> 1
Bnet.moo.com
For routing daemons from release 6, the cost of every path is always 1, and you
cannot change this value. You can set a higher value for path costs only when
configuring routers from release 7 or later.
Subject Import You can annotate subject gating for import subjects with weight values. When a
Weight message could travel two paths with equal cost, import weights break the tie.
Routing protocols seek the path with the greatest weight.
For example, in Figure 12, the administrator has specified that G imports foo.>
with weight 1 (retaining the default weight), and bar.> with weight 10.
Conversely, H imports foo.> with weight 10, and bar.> with weight 1. When all
the components operate properly, messages with subjects foo.> travel through F
and H, while messages with subjects bar.> travel through E and G. If E were to
fail, all messages would travel through F and H (because that route has the lowest
path cost).

76
See Also To configure path cost between neighbors, see Neighbor Interfaces on page 117.
To configure path cost from a router instance to a local network, see Local
Networks Configuration on page 113.
To configure subject import weight, see Subject Gating on page 115.

Independent Routing Table Entries in One Process 77
|
Independent Routing Table Entries in One Process
In most situations, each routing daemon process embodies a single routing table
entry. Nonetheless, in rare situations one routing daemon process can embody
several routing table entries. Each entry defines a separate and independent
software router, but without the cost associated with process switching.
This section explores two situations in which multiple routing table entries are
appropriate:
• Overlapping Subject Space
• Bandwidth Contention on page 79
Overlapping Subject Space

Consider two distinct distributed programs that use overlapping subject spaces—
that is, they use some of the same subjects for their messages. When the two
programs are deployed on the same physical network, each one receives
messages from the other, which is inappropriate. To eliminate interference within
the network, isolate each program to a separate UDP or PGM service.
Yet this solution within one network does not ordinarily keep the subject spaces
separate when routing daemons connect two or more networks, because the
routing daemon merges the subject spaces of its local networks.

78
Figure 13 Routing Daemons Merge Subject Spaces
Legend
Local Network
Neighbor Link
Routing Daemon
S1 L2
1.K.foo.com 2.K.foo.com 3.J.foo.com 4.J.foo.com

Net K.foo.com Net K.foo.com Net J.foo.com Net J.foo.com
UDP 7502 UDP 7500 UDP 7577 UDP 7588
A.K.foo.com F.J.foo.com
For example, on the left side of Figure 13, the two UDP or PGM services 7500 and
7502 effectively separate one physical network (K.foo.com) into two disjoint
subject spaces; that is, program L2 cannot receive messages from program S1.
Similarly, on the right side of Figure 15, two UDP or PGM services 7577 and 7588
effectively separate one physical network (J.foo.com) into two disjoint subject
spaces. However, the routing daemons in this configuration merge the subject
spaces of their local networks—effectively canceling the separation; that is,
program L2 does receive messages from program S1.
To restore the separation, configure an independent routing table entry for each
local network, as in Figure 14 on page 79.

|
Figure 14 Independent Routing Table Entries Keep Subject Spaces Separate
Legend
Local Network
Neighbor Link
Routing Table Entry
rvrd Process
S1 L2 S2 L3 L4
1.K.foo.com 2.K.foo.com 3.J.foo.com 4.J.foo.com

Net K.foo.com Net K.foo.com Net J.foo.com Net J.foo.com
UDP 7502 UDP 7500 UDP 7577 UDP 7588
A.K.foo.com F.J.foo.com
B.K.foo.com G.J.foo.com
In Figure 14, each rvrd process contains two independent routers, which act as
parts of two disjoint routes—keeping the data and subject spaces separate:
• Routing table entries A and F form a route connecting network 2 with
network 3.
• Routing table entries B and G form a route connecting network 1 with
network 4.
Notice that once again, program L2 cannot receive messages from S1.
Bandwidth Contention
Bandwidth contention is the second reason to separate programs using disjoint
routes.

80
Consider two programs that are deployed on the same physical network—a
program S2 that sends messages at a moderate data rate, and a program S1 that
sends messages at a relatively high data rate. However, messages from S2 are
much more important to the enterprise as a whole than messages from S1.
When forwarding these messages across a WAN, routing daemons would
ordinarily send them across the same TCP connection. The many unimportant
messages from S1 could delay the more important messages from S2.
To solve this throughput problem, configure an independent route for each set of
messages, as in Figure 14 on page 79. On the left side of Figure 14, S1 and S2 use
distinct UDP or PGM services within the same physical network, effectively
separating their messages into two logical network spaces. Disjoint routes carry
the two sets of messages:
• Important messages from S2 travel through routing entries A and F.
• Messages from S1 travel through routing entries B and G.
The heavy volume on this route does not interfere with crucial message
throughput on the S2 route, because a separate TCP connection carries each
route.
Defeating Independence
The routing table entries within an rvrd process operate as independent
pathways; that is, data does not flow directly between routing table entries within
a routing daemon process instance.
Nonetheless, data can flow indirectly by way of a mutual neighbor. In Figure 15
on page 81, notice that adding a neighbor link between M and T would merge the
route connecting networks A, B and C, with the otherwise disjoint route
connecting X and Y (defeating their independence). Use caution when altering a
network of routing daemons.

|
Figure 15 Mutual Neighbors Merge Routes
Legend C
Local Network
Neighbor Link
M.C.foo.com
Routing Table Entry
rvrd Process
A B
A.A.foo.com S.B.foo.com
B.X.foo.com T.Y.foo.com
X Y

82
Common Topology Errors
This section describes two variants of an erroneous routing configuration.
Neighbors on the Same Network

It is an error to configure two neighbors to serve the same logical local network
(network and service).
Since no gain could possibly result from forwarding messages from a network to
the same network, it might seem that this error is rather rare. Nonetheless, in
actual practice this error occurs rather frequently as an oversight.
Consider the situation in Figure 16 on page 83. In the desired outcome, neighbors
on computers gemini and taurus exchange messages on UDP or PGM service
7500 between the two networks, Castor.star.com and Pollux.star.com.
Because computer gemini has two network interfaces, the administrator attempts
to limit rvrd operation to only Castor.star.com. Nonetheless, the routing
daemon on gemini still receives messages from Pollux.star.com through its
other interface (to understand the reason for this behavior, see Limitation on
Computers with Multiple Network Interfaces on page 25). Because the two
neighbors both serve the same network, Pollux.star.com, erroneous behavior
results.
If gemini had only one network interface, Castor.star.com, the routing
daemons would operate correctly.
When the routing daemon detects a topology error of this kind, it outputs an error
message. Administrators must correct this situation immediately.

Common Topology Errors 83
|
Figure 16 Erroneous Neighbors on the Same Network
Legend
Local Network
Neighbor Link
Routing Daemon
Net Castor.star.com
UDP 7500
gemini taurus
Net Pollux.star.com Net Pollux.star.com

UDP 7500 UDP 7500
Duplicating Effort
It is an error to use routing daemons to duplicate the effort of another forwarding
mechanism (for example, a hardware router, or another pair of routing daemon
neighbors. (This error is actually a variation of the error described in Neighbors
on the Same Network on page 82.)
Consider the situation in Figure 17 on page 84. Two mechanisms forward
messages between the two networks—the hardware router and a pair of routing
daemons (A.a.bad.com and B.b.bad.com). When a program on network
a.bad.com sends a message, routing daemon A forwards it to its neighbor B,
which redistributes it on network b.bad.com. When the hardware router receives
the redistributed message, it forwards it back to network a.bad.com, where A
detects the duplication and produces an error message.
This kind of error can occur in either broadcast or multicast situations. However,
it is especially common in environments where hardware routers enable multicast
routing. Upgrading a hardware router can trigger this error.

84
Upgrading rvrd from release 5 to release 6 (or later) provides another fertile
environment for this error. When both routing daemons run concurrently in the
same network, be careful to avoid duplicate service.
To repair the situation, remove one of the routing daemons, or disable hardware
multicast routing.
Figure 17 Routing Daemons and Duplication
Legend
Local Network
Network Interface
Erroneous Neighbor Link
Path of Message
Routing Daemon
Net a.bad.com
UDP 7533
A.a.bad.com
Hardware
Router
B.b.bad.com
Net b.bad.com
UDP 7533

Security and Firewalls 85
|
Security and Firewalls
Routing daemons offer security controls based on UDP or PGM service groups
and subject names (see Restricting Message Flow on page 63). In addition, the
routing daemon works in concert with firewalls to constrain information flow.
The WAN in Figure 18 connects two enterprises across the Internet. Each
enterprise protects its networks with firewalls. Notice that the routing daemon
within the DMZ does not serve any local network; instead that routing daemon
operates as a way station, forwarding messages across the firewalls on either side
of it.
Figure 18 Routing Daemon WAN with Firewalls
Enterprise 1 Enterprise 1 Enterprise 1

Legend Net D Net E Net F
Local Network
Neighbor Link Enterprise 1 Enterprise 1 Enterprise 1

Net A Net B Net C
Routing Daemon
Firewall Firewall
Enterprise 1
DMZ
Internet
Firewall Firewall
Enterprise 2
DMZ
Enterprise 2 Enterprise 2 Enterprise 2

Net X Net Y Net Z

86
Neighbors Across a Firewall

Firewalls restrict the flow of information across organizational boundaries. For
Rendezvous messages to flow between routing daemons, the daemons must
establish TCP connections between neighbors. Security administrators can permit
this connection using any technique they prefer; for example:
• Configure the firewall to permit SSL connections on the routing daemon’s
local port. Configure the routing daemons to connect with one another using
SSL neighbor connections.
• Configure VPN connectivity between neighbor host computers.
• Configure the firewall to permit TCP connections on the routing daemon’s
local port.
• Configure the neighbors to connect using an SSH tunnel through the firewall.

Connecting PGM and TRDP Networks with Routing Daemons 87
|
Connecting PGM and TRDP Networks with Routing Daemons
PGM and TRDP network protocols do not interoperate. Nor can Rendezvous
components and programs from one variant interoperate with components and
programs from the other variant. The only exception to this rule is the
Rendezvous routing daemon.
You can deploy a pair of Rendezvous routing daemons to construct a bridge that
connects a PGM network with a TRDP network. This bridge lets PGM programs
in one network communicate with TRDP programs in the other network.
Figure 19 depicts an example. A routing daemon from the TRDP variant runs in
the TRDP network, while a routing daemon from the PGM variant runs in the
PGM network. The two routers specify each another as neighbors. They forward
both multicast and point-to-point messages.
Figure 19 Bridge PGM and TRDP Networks with rvrd

TRDP Network PGM Network
UDP 8100 PGM 8150
TRDP rvrd PGM rvrd
The two networks need not be physically distinct. For example, you can run PGM
and TRDP variants on the same physical LAN—as long as they use
non-overlapping services (that is, port numbers).

88
Backlog Protection
Every WAN connection has a maximum capacity. Routing daemons cannot

exceed this physical limitation. When the volume of routed data is greater than
WAN capacity, rvrd buffers the outbound data.
Data backlog can occur in several scenarios; for example:
• An unexpected burst of data exceeds WAN capacity.
• A temporary problem with the WAN sharply decreases its capacity.
• WAN capacity is insufficient for the required volume of data.
• WAN capacity is generally sufficient, but rvrd is misconfigured to route more
data than expected. The total data volume exceeds WAN capacity.
The Connected Neighbors page displays the peak backlog for each neighbor; see
Connected Neighbors on page 103.
Maximum Backlog
An extremely large backlog can cause severe problems for rvrd and its host
computer. Administrators can configure rvrd to protect against this possibility.
When enabling this feature, the administrator specifies the maximum permissible
backlog (in kilobytes). When an outbound backlog of this size accumulates for
any neighbor connection, rvrd automatically disconnects from that neighbor,
clears the corresponding outbound data buffer, and attempts to reconnect to the
neighbor.
To obtain a reasonable estimate for the threshold value that triggers this action,
calculate the process storage available to rvrd, divided by the number of
neighbor connections it serves.
You can configure this feature separately for each routing table entry. The router
applies that maximum to all of its neighbor connections.
To configure this feature, see Routers on page 111.
Notice that enabling this feature represents a deliberate decision to discard data in
certain extreme circumstances. When this feature is disabled (the default), the
routing daemon does not protect against backlog. The decision to use this feature
must be based on the business requirements of the enterprise.

Idle 89
|
Idle
rvrd can run in either of two states—running or idle.

When running, rvrd establishes neighbor connections and routes messages.
When idle, rvrd does no routing operations. However, the browser administration
interface is available for configuring parameters. The process still behaves as a
Rendezvous daemon (rvd).
While rvrd is in idle state, you can configure the routing table and other
parameters without affecting the network in any way, without binding local
resources (such as UDP or PGM services or TCP ports), and without resolving any
names in the routing table. After saving the configuration in a store file (and
terminating the rvrd process), you can restart rvrd using the stored
configuration. Alternatively, you can move the store file to another host computer,
and start rvrd there.

90
Routing Daemon Logging
A routing daemon process can output a running log of its activity. System
administrators can use the resulting log files to monitor neighbor connections,
subject interest and message flow.
To configure the kinds of normal activity to log, see Logging on page 110.
To configure the destination of log output, see Log Destination on page 43.
The command line parameter -log is obsolete in release 6 (and later). Use the
browser administration interface to configure rvrd logging categories.
Interpreting Log Output

Each line in the log file describes a significant event in the operation of a routing
daemon. A time stamp indicates the date and time of the interaction. The
remainder of the line is a string describing the event.
The log file begins with events in the routing daemon’s start sequence. First, it
discovers its hardware and software operating environment:
2002-04-22 10:07:46 ./rvrd: Hostname: bigdog.rv.tibco.com
2002-04-22 10:07:46 ./rvrd: Hostname IP address: 10.101.2.35
2002-04-22 10:07:46 ./rvrd: Detected IP interface: 127.0.0.1 (lo)

2002-04-22 10:07:46 ./rvrd: Detected IP interface: 10.101.2.35 (eth0)
2002-04-22 10:07:46 ./rvrd: Detected IP interface: 10.101.4.35 (eth2)
2002-04-22 10:07:47 ./rvrd: Using ticket file /rv/src/dev/btools/minclude/tibrv.tkt
2002-04-22 10:07:47 ./rvrd: Using store file 20020419.1.rvrd.str
2002-04-22 10:07:47 ./rvrd: Initializing random pool...
Next, the routing daemon reads its configuration from its store file. In this
example, it defines a router (routing table entry) named bigdog-r1, with an accept
any neighbor interface.
2002-04-22 10:07:47 ./rvrd: [bigdog-r1]: Defined.

2002-04-22 10:07:47 ./rvrd: [bigdog-r1]: Any neighbor is allowed to connect to local
port 9666. Link cost: 1.
The example continues by defining that a local network interface (for router
bigdog-r1), and subject gating for that local network.

Routing Daemon Logging 91
|
2002-04-22 10:07:47 ./rvrd: [bigdog-r1]: Local network sunfire-bigdog-n1 defined.
Interface: 10.101.2.35. Service UDP port: 7666, Service spec: 7666, Network spec:
;224.9.9.9. Link cost: 1.
2002-04-22 10:07:47 ./rvrd: [bigdog-r1]: Export subject [>] from local network
sunfire-bigdog-n1.
2002-04-22 10:07:47 ./rvrd: [bigdog-r1]: Import subject [>] with weight 10 for local
network sunfire-bigdog-n1.
The routing daemon finishes its start sequence by reporting the URL bindings of
its browser administration interfaces.
2002-04-22 10:07:47 ./rvrd: Http interface - http://bigdog.rv.tibco.com:7680/
2002-04-22 10:07:47 ./rvrd: Https interface - https://bigdog.rv.tibco.com:36145/
Now the routing daemon begins normal operations. The administrator sets the
logging parameters for normal activity. After that, log items reflect neighbor
connections to other routers (viggen-r1), exchange of subscription interest
information, and forwarding of message data.
2002-04-22 10:08:35 ./rvrd: Logging: [Connections - On], [Subject Interest - On],
[Subject Data - On].
2002-04-22 10:13:26 ./rvrd: [bigdog-r1]: Connected to viggen-r1.
2002-04-22 10:15:40 ./rvrd: [bigdog-r1]: Sending subscription for [TEST] to

viggen-r1 for source 0A65023F/hpux11-viggen-n1.
2002-04-22 10:16:30 ./rvrd: [bigdog-r1]: Received data on [TEST] from neighbor
viggen-r1.
2002-04-22 10:18:03 ./rvrd: [bigdog-r1]: Sending cancel for [TEST] to viggen-r1 for
source 0A65023F/hpux11-viggen-n1.
2002-04-22 10:19:31 ./rvrd: [bigdog-r1]: Disconnected from viggen-r1 (4).

92
rvrd
Command
Syntax rvrd -store <filename>

[-http [<ip_address>:]<http_port>]
[-https [<ip_address>:]<https_port>]
[-http-only]
[-no-http]
[-idle]
[-no-multicast]
[-foreground]
Purpose The routing daemon efficiently connects Rendezvous programs on distant IP

networks, so that messages flow between them as if within a single network.
Nonetheless, communicating programs remain decoupled from internetwork
addresses and other details.
Remarks The rvrd process subsumes the behavior of rvd, so it is not necessary to run a
separate rvd process on computers that run rvrd. We recommend against running
both components on the same computer.
rvrdmust run on a host computer with a permanent IP address. For example, a
temporary address assigned by DHCP is invalid.
(Sheet 1 of 4)
-store <filename> This file contains the routing table entry and parameters that
configure rvrd.
rvrd reads this file when the process starts, and writes this file
each time you change the configuration using the browser

rvrd 93
|
(Sheet 2 of 4)
this HTTP or HTTPS port. Permit administration access only
-http <http_port>
through the network interface specified by this IP address.
-https <ip_address>:<https_port> To limit access to a browser on the rvrd host computer, specify
-https <https_port>
HTTP or HTTPS port.
exits.
When the -http parameter is entirely absent, the default
behavior is to accept connections from any computer on HTTP
port 7580; If this default port is unavailable, the operating
system assigns an ephemeral port number.
When the -https parameter is entirely absent, the default
behavior is to accept secure connections from any computer on
an ephemeral HTTPS port.
In all cases, the program prints (in its start banner) the actual
HTTP and HTTPS ports where it accepts browser
administration interface connections.
-http-only Disable HTTPS (secure) connections, leaving only an HTTP

(non-secure) connection.
-no-http Disable all HTTP and HTTPS connections, overriding -http

and -https.
-idle When present, start rvrd in its idle state.

When absent, start rvrd in its running state—routing
messages.

94
(Sheet 3 of 4)
-listen <ip_address>:<tcp_port> rvd (and by extension, rvrd operating within the local
network) opens a TCP client socket to establish
-listen <tcp_port>
-listen parameter specifies the TCP port where the
client programs. This -listen parameter of rvd corresponds
to the daemon parameter of the transport creation call (they
must specify the same TCP port number).
this daemon accepts TCP connections.

connections from any computer on the specified TCP port.
to accept connections from any computer on TCP port 7500.

parameter.
-no-multicast When present, the daemon disables multicast (and broadcast)

communication. For details, see Disabling Multicast on
page 32.

rvrd 95
|
(Sheet 4 of 4)
-reliability <time> Rendezvous daemons compensate for brief network failures
by retaining outbound messages, and retransmitting them
upon request.
If this parameter is absent, the default retention time is 60
seconds. In some situations, shorter times are appropriate. We
strongly discourage increasing the retention time beyond 60
seconds (see Reliability and Message Retention Time on
page 41).
If this parameter is present, rvd (and by extension, rvrd
operating within the local network) retains messages for <time>
(in seconds).
For more information see Reliability and Message Retention
Time on page 41.

-log-rotate <size> When present, activate the log rotation regimen (see Log
Rotation on page 43), limiting the combined total size of the 10
log files to this size (in kilobytes).
When you specify this option, you must also specify
-logfile.
-log-config <config_log_filename> Send duplicate log output to this file for log items that record
configuration changes. The daemon never rotates nor removes
this special log file. Instead, this file remains as a record of all
configuration changes.

When present, rvrd runs as a foreground process.
When absent, rvrd runs as a background process.

96
Browser Administration Interface—rvrd
The browser administration interface lets you control rvd from a web browser.
You can configure its operating parameters, and view operating statistics.
Topics
• Local Networks, page 101
• Connected Neighbors, page 103
• Daemon Parameters, page 108
• Routers, page 111
• Local Networks Configuration, page 113
• Subject Gating, page 115
• Neighbor Interfaces, page 117
• Certificates, page 123

Navigation 97
|
Navigation
Figure 20 rvrd Navigation Panel

98


page 50.
Local This page summarizes the local networks of a router; see Local
Networks Networks on page 101.
Connected This page summarizes the actual neighbor connections of a

Neighbors router; see Connected Neighbors on page 103.

on page 52.
Configuration Daemon This page lets you configure parameters that control
Parameters configuration access and router logging; see Daemon
Parameters on page 108.
Routers This page lets you configure routers. You can access additional
configuration pages through links on this page. See Routers on
page 111, and the sections that follow it.
XML This page lets you view the current configuration as an XML
Configuration document, and reconfigure the component by submitting an
edited XML document.
Certificates This page lets you configure certificates that the daemon uses
to identify itself in secure protocols. See Certificates on
page 123.
Log Out This item logs out the current user or Administrator. See Log
Out on page 110.

Rendezvous
Web Page

|
General Information
rvrd (like all Rendezvous components) displays information about itself on this
page.
the rvrd browser administration interface.
Figure 21 rvrd General Information Page
(Sheet 1 of 2)
Item Description
component The name of the program—rvrd (or rvsrd).
client port The TCP port where the daemon listens for client connections.

100
(Sheet 2 of 2)
Item Description
services
routing The number of router names that this daemon embodies; see Routing Table Entry
names on page 65.
store file File name of the daemon’s store file; see the command line parameter -store for
rvsd on page 139, and for rvsrd on page 142.

Local Networks 101
|
Local Networks
rvrd displays information about its local networks on this page.

To display this page, click Local Networks in the left margin of any page of the
rvrd browser administration interface.
Figure 22 rvrd Local Networks Page
(Sheet 1 of 2)
Item Description
Router Name This page groups local networks by router name (routing table entry). A box in
this column indicates the name of the routing table entry that serves the local
networks shown to its right. See also Routing Table Entry on page 65.
Local Network The name of a local network.

Name
Service The UDP or PGM service for communication on the local network.
Network The network specification (as specified by the routing table entry).
Specification
Local Routers This subtable lists other routers that serve this local network.

102
(Sheet 2 of 2)
Item Description
Hostname The name of the host computer where the other routing daemon runs.
Click here to view the browser administration interface for the other routing
daemon process.
IP Address The IP address of the host computer where the other routing daemon runs.
Version The version of the other routing daemon executable.
Subscriptions A list of subscription interest registered by all transports within the local
network.
Limited to 50 subscriptions; if greater than 50, it displays only the approximate
number of subscriptions.

Connected Neighbors 103
|
Connected Neighbors
rvrd displays information about its (actual) neighbor connections on this page.
To display this page, click Connected Neighbors in the left margin of any page of
This page is related to—but not the same as—the page described in Neighbor
Interfaces on page 117.
Figure 23 rvrd Connected Neighbors Page
(Sheet 1 of 2)
Item Description
table rows Each row in this table describes one neighbor connection.
Router Name This page groups neighbors by local router name (routing table entry). A box in
this column indicates the name of the local router that connects to the neighbors
show to its right. See also Routing Table Entry on page 65.
Neighbor The name of a remote router with which the local router has a neighbor
Name connection.
Click here to view the browser administration interface for the neighbor routing
daemon process.
Link Stats The name of the (local) neighbor interface that specifies this neighbor connection.
rvrd generated this name automatically when you configured the neighbor
interface. Click this name to view the Neighbor Statistics page.

104
(Sheet 2 of 2)
Item Description
Peak Backlog Backlog is outbound data awaiting transmission to a neighbor. This column
displays the peak backlog for each neighbor.
The Reset Statistics button on the Neighbor Statistics page resets this figure to
zero. It is also reset to zero when the neighbors become disconnected and
subsequently reconnect.
See also, Backlog Protection on page 88.
Neighbor Statistics
rvrd displays statistics about the performance of a neighbor connection on this
page.
To display this page, click the Link Stats column of the Connected Neighbors
page.

|
Figure 24 rvrd Neighbor Statistics Page
(Sheet 1 of 3)
Item Description
summary This list presents static information about the neighbor connection.
Router Name The name of the local router. (See also Routing Table Entry on page 65.)
Neighbor Name The name of the neighbor (remote router).
Interface Number The name of the (local) neighbor interface that specifies the neighbor
connection. rvrd generated this number automatically when you configured
the neighbor interface, and incorporates it into the neighbor ID.
Local Port TCP port that this router uses to communicate with the neighbor.

106
(Sheet 2 of 3)
Item Description
Remote Port TCP port that the neighbor (remote router) uses to communicate with the local
router.
Cost Path cost of the neighbor link.
SSL Connection SSL security feature for the neighbor link.
Data Data compression feature for the neighbor link.

Compression
Backlog Limit When backlog protection is enabled, this item displays the threshold for
disconnect from the neighbor. See Backlog Protection on page 88.
Data Flow This table displays statistics about the volume of data on the neighbor
connection.
The Inbound row displays statistics about inbound data from the remote
neighbor to the local router.
The Outbound row displays statistics about outbound data from the local
router to the remote neighbor.
Messages Cumulative count of messages.
Bytes Cumulative count of bytes (without compression).
Bytes/Sec Data transmission rate during the most recent interval.
Compr Bytes Cumulative count of compressed bytes.

This item displays non-zero only when both of the neighbors specify data
compression on the rvrd Neighbor Interface Configuration Form.
Compr Ratio Compression ratio.

This item displays non-zero only when both of the neighbors specify data
compression on the rvrd Neighbor Interface Configuration Form.
Miscellaneous This table displays statistics not related to either inbound or outbound data
Statistics transmission.
Peak Backlog Peak backlog of outbound data (in bytes) since the last reset of statistics. See
also, Backlog Protection on page 88.

|
(Sheet 3 of 3)
Item Description
Curr Backlog Current backlog of outbound data (in bytes). See also, Backlog Protection on
page 88.
Reconnects Cumulative count of times when the neighbor link became disconnected and
subsequently reconnected. (For example, network failure or backlog protection
could cause a disconnect.)
Total Inbound Cumulative counts of inbound and outbound bytes (without compression)
since the start of the neighbor connection. The Reset Statistics button does not
Total Outbound
affect these items.
Reset Statistics Click this button to reset statistical counters to zero.

108
Daemon Parameters
This page lets you configure parameters that affect overall daemon security.
To display this page, click Daemon Parameters in the left margin of any page of
Figure 25 rvrd Daemon Parameters Page
Administrator and Password

Only authorized personnel have access to routing daemons.
When administrator identification information is not set, anyone who can connect
to the browser administration interface can examine and reconfigure the daemon.
This arrangement can be useful during initial configuration and testing phases.
However, during regular operation we recommend limiting access.

Daemon Parameters 109
|
Once administrator identification information is registered, the browser

administration interface is locked against unauthorized access. The daemon
prompts administrators to prove identity by typing a name and password. After
providing proper identification, an authorized administrator is logged in, and has
complete access to configure the daemon. If the administrator does not provide
proper identification, the browser displays the General Information page and
continues to prompt for a correct name and password.
Browsers remember administrator name and password information for the

duration of the browser process. Merely closing the browser window does not
erase this information. To guard against intruders you must terminate the
browser process (all its windows).
Primary The first administrator to register is called the primary administrator. In addition to
Administrator configuring the daemon, the primary administrator can also add, delete and
modify identification information pertaining to the other administrators.
Each daemon configuration can store up to 16 additional administrator name and
password pairs (after the primary administrator).
One Each daemon process permits only one administrator session at a time. When one
Administrator administrator is logged in, other administrators are locked out; this prevents
Session conflicts in which two administrators attempt to modify the configuration at the
same time. To terminate a administrator session, see Log Out (below).
(Sheet 1 of 2)
Item Description
Name Type a name string.
Password Type a password string.
Confirm Password Type the password again.
Add/Update Specify a name and password, then click this button to

add a new administrator.
The primary administrator can add other
administrators and update their passwords. All other
administrators can update only their own passwords.

110
(Sheet 2 of 2)
Item Description
Delete Click this button to delete administrator identification
information.
This action is available only to the primary
Administrator.
Deleting the primary administrator also deletes all
other administrator.
Log Out
To end an administrative session, click Log Out in the left margin of the browser
administration interface. This item appears only when you are logged in as an
Administrator.
Daemons automatically log out administrator sessions that have been idle for 10
minutes.
Logging
This panel configures the kind of routing activity that the routing daemon
routinely outputs to its log file.
Item Description
Connections Log connection activity whenever this routing daemon
establishes or closes a connection to a neighbor.
Subject Interest Log all subscription requests (notification of listening) that

this routing daemon sends to its neighbors or receives from
its neighbors.
Subject Data Log all messages that this routing daemon forwards to its
neighbors or receives from its neighbors.
To configure the destination of log output, see Log Destination on page 43.
To interpret the content of log output, see Routing Daemon Logging on page 90.

Routers 111
|
Routers
This page lets you configure routing table entries (router names). For more
information, see Routing Table Entry on page 65.
To display this page, click Routers in the left margin of any page of the rvrd
Identify each routing table entry by a globally unique name.
You can add a new entry or remove an existing entry at any time.
For background information, see Routing Table Entry on page 65, and
Independent Routing Table Entries in One Process on page 77.
Figure 26 rvrd Routers Page
(Sheet 1 of 2)
Item Description
Existing This panel lists the routing table entries within this routing daemon process. Each
Routers row represents one routing table entry.

112
(Sheet 2 of 2)
Item Description
Router Name This column displays the router name of a routing table entry.
Click here to set the maximum backlog for the routing table entry; see Backlog
Protection on page 88.
Local Network The number of local networks configured for a routing table entry.
Click here to view the Local Networks Configuration on page 113 page.
Neighbor The number of neighbors configured for a routing table entry.

Click here to view the Neighbor Interfaces on page 117 page.

Local Networks Configuration 113
|
Local Networks Configuration
This page lets you configure local networks for a routing table entry.
To display this page, click the number of local networks in a row of the Routers
page.
For background information, see Local Network on page 66.
This page is not the same as the page described in Local Networks on page 101.
Figure 27 rvrd Local Networks Configuration Page
(Sheet 1 of 2)
Item Description
existing local networks The upper table lists local networks. Each row represents one local
network.

114
(Sheet 2 of 2)
Item Description
Local Network Name The name of a local network. Local network names must be globally
unique.
To configure subject gating for a local network, click its name in the table of
existing local networks.
For more information, see Local Network on page 66.
Service The UDP or PGM service for communication on a local network. Programs
within the local network communicate using this service.
For more information, see Specifying the UDP or PGM Service on page 21.
Network The network specification for a local network.

Specification
For more information, see Constructing the Network Parameter on
page 23.
Cost Path cost for routing between a local network and the routing daemon.
For more information, see Load Balancing on page 74.
Add Local Network To add a new local network, type the specifications and click this button.
Interface

Subject Gating 115
|
Subject Gating
This page lets you configure subject gating (import and export subjects) for a local
network.
To display this page, click the name of a local network in a row of the Local
Networks Configuration page.
For background information, see Subject Gating on page 66, and Subject Filtering
with Wildcards on page 67.
Figure 28 rvrd Subject Gating Configuration Page
(Sheet 1 of 2)
Item Description
Import Subjects This table lists import subjects.
The local network can import subjects that match these names. You can
remove a subject at any time.

116
(Sheet 2 of 2)
Item Description
Export Subjects This table lists export subjects.
The local network can export subjects that match these names. You can
remove a subject at any time.
adding subjects To add subjects, specify the subject string (which may contain wildcards)
here, and click one of three buttons:
• Import
• Export
• Import and Export
See also Subject Import Weight on page 75.

Neighbor Interfaces 117
|
Neighbor Interfaces
This page lets you configure the potential neighbor connections of a routing table
entry.
To display this page, click the number of neighbors in a row of the Routers page.
For background information, see Neighbors on page 69.
This page is related to—but not the same as—the page described in Connected
Neighbors on page 103.
Existing Neighbor Interfaces

The first part of this page is a table of existing neighbor interfaces—that is,
interface specifications for potential neighbor connections to other routers.
Figure 29 rvrd Neighbor Interfaces Page—Existing
(Sheet 1 of 2)
Item Description
existing neighbor The upper table lists configured neighbor interfaces. Each row represents
interfaces one potential neighbor.
Interface ID The name of this neighbor interface. rvrd generates this name
automatically, incorporating the router name.

118
(Sheet 2 of 2)
Item Description
Local Endpoint This three-part string denotes the local end of the potential neighbor link. It
has the form:
<router_name>@<host>:<TCP_connect_port>
• <router_name> is the name of the local routing table entry.

• <host> is a fixed token, Local_Host, which denotes the local rvrd host
computer. (Note that this token does not denote the LOCALHOST
loopback network address.)
• <TCP_connect_port> is the TCP port where the local router accepts
neighbor connection requests from remote routers.
Remote Endpoint This three-part string denotes the remote end of the potential neighbor
link. It has the form:
<router_name>@<host>:<TCP_connect_port>
• <router_name> is the name of the remote routing table entry.

• <host> is the hostname or IP address of the remote rvrd host computer.
• <TCP_connect_port> is the TCP port where the local router attempts to
connect to remote routers.
The token Any can appear in these three parts. For the semantics of this
notation see Accept Any as Neighbor on page 72, and Seek Neighbor with
Any Name on page 72. See also, Four Variations of the Form on page 120.
Features This column lists optional features of this neighbor specification:

• Cost: the path cost of this neighbor link (see Load Balancing on
page 74)
• Compression: this flag indicates whether this interface specifies data
compression (see Data Compression on page 70)
• SSL: this flag indicates whether this interface requires an SSL
connection (see SSL Connection with Compression on page 122)
See Also Router Name on page 65

|
Add New Neighbor Interface

The remainder of this page lets you complete a form to specify a new neighbor
interface.
Figure 30 rvrd Neighbor Interface Configuration Form

120
Four Variations of the Form

Four buttons rearrange the form into four variations, each with a different
meaning (see Table 7). In each variation, rvrd automatically fills in some fields,
and leaves others empty for you to fill.
Table 7 Four Neighbor Interface Configuration Forms
Item Description
Accept Any Use this variation of the form to specify a neighbor interface in which this routing
daemon accepts neighbor connections from any other routing daemon.
It is not possible to configure more than one accept any neighbor interface. This
variation cannot use SSL neighbor connections.
A distinguishing characteristic of accept any neighbors is a remote endpoint string
in which the router name, the host and the port are all Any.
For more information, see Accept Any as Neighbor on page 72.
Passive Use this variation of the form to specify a neighbor interface in which the local
router does not actively attempt to connect to the remote neighbor. Instead, it
passively waits for the remote neighbor to request a connection.
A distinguishing characteristic of passive neighbors is a remote endpoint string in
which the router name is specified, but the host and port are Any.
For more information, see Passive Neighbor on page 71.
Active Use this variation of the form to specify a neighbor interface in which the local
router actively attempts to connect to the remote neighbor.
A distinguishing characteristic of active neighbors is a remote endpoint string in
which the router name, the host and the port are all specified.
For an example, see Active Neighbor on page 71.
Seek Any Use this variation of the form to specify a neighbor interface in which this routing
daemon attempts to connect to any remote routing daemon that matches the
specification.
It is illegal to configure two or more seek any neighbor interfaces with the same
host. This variation cannot use SSL neighbor connections.
A distinguishing characteristic of seek any neighbors is a remote endpoint string in
which the router name is Any, but the host and the port are specified. In addition,
the local endpoint port is Any.
For more information, see Seek Neighbor with Any Name on page 72.

|
Items in the Neighbor Interface Configuration Form

This table describes the items in Figure 30 on page 119.
(Sheet 1 of 2)
Item Description
Local This three-part specification denotes the local end of the potential neighbor link:
Endpoint
• Router Name is the name of the local routing table entry. rvrd always
automatically fills in this name.
• Host is a hostname or IP address corresponding to a network interface in the
local rvrd host computer. For convenience, rvrd automatically fills in this field
with the fixed token, <local_host>, which denotes the default network
interface of the local rvrd host computer. (Note that this token does not denote
the LOCALHOST loopback network address.) You may override this default value
by typing an alternate hostname or IP address.
• TCP Connect Port is the local TCP port where the local router accepts neighbor
connection requests from remote routers. For more information, see Local
Connect Port on page 69.
Remote This three-part specification denotes the remote end of the potential neighbor link:
Endpoint
• Router Name is the name of the remote routing table entry.
• Host is the hostname or IP address of the remote rvrd host computer.
• TCP Connect Port is the remote TCP port where the local router attempts to
connect to remote routers.
For more information, see Remote Connection Information on page 69.
Normal With this option, the two neighbors neither compress data nor use SSL protocols
Connection for communication on the link between them.
Data With this option, the two neighbors compress data on the link between them. To
Compression enable compression, you must select this option on both neighbors. For more
without SSL information, see Data Compression on page 70.

122
(Sheet 2 of 2)
Item Description
SSL With this option, the two neighbors communicate using both compression and SSL
Connection protocols. To enable SSL, you must select this option on both neighbors—otherwise
with they cannot establish a connection.
Compression
This option appears only in the Passive and Active variations of the configuration
form.
In older releases of the routing daemon, SSL and compression are mutually
exclusive features. For backward compatibility with older neighbors, this feature
degrades gracefully to SSL without compression.
Certificate of In SSL protocols, the local router expects the remote router to present this certificate
Expected as evidence of its identity. Paste the text of the public certificate (in PEM encoding)
Peer in this field.
This field appears only in the Passive and Active variations of the configuration
form.
Cost The path cost of this neighbor link (see Load Balancing on page 74).

Certificates 123
|
Certificates
This page lets you configure the X.509 certificates that the routing daemon uses to
identify itself.
To display this page, click Certificates in the left margin of any page of the rvrd
For background information, see Certificates and Security on page 53 in TIBCO
Each daemon process keeps a list of certificates it can use to identify itself. These
certificates are numbered for easy reference. The first panel on this page
determines which of these certificates the daemon uses for particular tasks. The
remainder of the page lets you enter the certificates.
Certificate Uses
Figure 31 rvrd Certificate Uses Form
Item Description
HTTPS Set the certificate for the secure browser administration interface.
To avoid security warnings from the web browser, distribute this certificate to
authorized administrators.
Routers to Set the certificate for secure SSL neighbor connections.

Routers
Distribute this certificate to each applicable neighbor.

124
Certificate List
Figure 32 rvrd Certificate List

Certificates 125
|
Item Description
certificate Use this number to refer to the certificate in the Certificate Uses panel.
number
Add from Enter a file name and a private key password. When you click Add from File, the
File daemon reads the certificate with private key from the file. The file may be in either
PEM encoding, or PKCS #12 format.
See also Security Factors on page 135.
Add from Paste the text of a certificate with private key. Enter a private key password.
Text
The certificate must be in PEM encoding.
Self-Signed Each daemon process creates a self-signed certificate at start time, and registers it
Certificate in the list as certificate #1. You may use that certificate as is, add other certificates
to the list, or delete it and enter other certificates.

126

| 127
Chapter 6 Secure Daemons (rvsd and rvsrd)
Release 7.0 introduces two new daemons, featuring SSL for secure connections to
client program transports:
• rvsd, the Rendezvous secure communications daemon, corresponds to rvd

• rvsrd, the Rendezvous secure routing daemon, corresponds to rvrd
This chapter describes the security features of these two daemons, and details the
parameters that differentiate them from their non-secure counterparts.
Topics
• Secure Daemon Overview, page 128

• Motivation, page 129
• Users, page 131
• Limiting Access, page 133
• Security Factors, page 135
• Behavioral Differences, page 137
• rvsd, page 139
• rvsrd, page 142
• Browser Administration Interface—rvsd and rvsrd, page 145

128
| Secure Daemons (rvsd and rvsrd)
Secure Daemon Overview
This chapter describes the two daemons that offer secure client connections:
• rvsd,the Rendezvous secure communications daemon, corresponds to rvd.
Chapter 4 describes rvd, the Rendezvous communications daemon.
• rvsrd,the Rendezvous secure routing daemon, corresponds to rvrd.
Chapter 5 describes rvrd, the Rendezvous routing daemon.
Secure Connections
The two ordinary Rendezvous daemons, rvd and rvrd, communicate with clients
over non-secure TCP connections. In contrast, their secure counterparts, rvsd and
rvsrd, communicate with clients over SSL connections, allowing secure client
communication over non-secure networks.
Restricting Access
Secure daemons restrict client access in three ways:
• Only authorized clients can connect to a secure daemon.
• Secure daemons restrict the combinations of network and UDP or PGM
service over which client transports can communicate.
• Secure daemons limit the subject space that its clients can access.
Plaintext Communication
Although they ensure secure client connections, both secure daemons transmit
messages as plaintext. That is, when they publish messages from clients to local
networks, those messages are not encrypted.
For message-level encryption, use TIBCO Rendezvous DataSecurity (RVDS); see
the documentation for that product.

Motivation 129
|
Motivation
Deploy secure daemons when clients must connect securely over a non-secure
network. This section illustrates example situations involving remote clients.
rvsd
Figure 33 depicts a hub and spoke architecture. An rvsd hub runs on a firewall
computer, and remote programs access the hub through secure SSL connections.
This arrangement lets trusted remote programs communicate with servers and
other programs inside the secure inner network. rvsd bars untrusted programs
from connecting to it.
Figure 33 rvsd—Secure Connections across Single Firewall
Program Program
Firewall
Remote
rvd rvd rvsd SSL
Programs
Secure Inner Net
rvsrd
Figure 34 rvsrd—Secure Connections across Double Firewall
SSL
Legend
rvrd rvsrd
Remote
Local Network SSL
Programs
Neighbor Link
Firewall Firewall
Routing Daemon Secure
DMZ
Inner Net

130
Figure 34 on page 129 depicts a situation with two Rendezvous routing daemons
configured to cross a double firewall. Remote programs initiate secure SSL
connections to a secure routing daemon hub (rvsrd) within the outer firewall
(DMZ network). A secure SSL neighbor link connects that secure routing daemon
with an ordinary routing daemon (rvrd) in the secure inner network.
To configure secure neighbor links, see SSL Connection with Compression on
page 122.
Preventing To prevent rvsrd from multicasting client messages within the DMZ network,
Multicast in the start rvsrd with the -no-multicast option. For background information, see
DMZ Disabling Multicast on page 32.
-no-multicast is available starting with Rendezvous release 7.2. This feature

replaces the following procedure , which was required in earlier releases:
• Configure rvsrd so that in all of its local networks, the network specification
is the loopback address (IP address 127.0.0.1). To configure, see Local
Networks Configuration on page 113.
• Similarly limit the access of client transports to network and service pairs in
which the network is the loopback address (IP address 127.0.0.1). To
configure, see Authorize Network and Service Pairs on page 158.

Users 131
|
Users
Each secure daemon instance authorizes a set of trusted users:

• The secure daemon allows a client transport to connect only if the client
presents valid identification as an authorized user.
• User identification can be either a certificate, or a user name and password.
To authorize a user, see Users on page 156.

To connect to a secure daemon as a user, see Secure Daemon on page 60 in TIBCO
Rendezvous Concepts, and the appropriate functions or methods in each
programming language API.
Certificate Identification
The secure daemon can register zero or more X.509 public key identity certificates
per user. The secure daemon limits access to user programs that can sign SSL
protocol messages with a corresponding private key.
The secure daemon accepts all certificates in either PEM encoding or PKCS #12
format.
User Name and Password Identification

The secure daemon registers at most one password per user. The secure daemon
limits access to user programs that supply a correct pair of user name and
password strings.
For important information about password security, see Security Factors on

page 135.
Syntax User name and password strings must conform to these syntax specifications:
• The user name must be less than 128 characters. The combined length of the
user name and password must be less than 250 characters.
• These strings must consist of printable characters only, from any character set.
Dot (.), star (*), and greater-than (>) characters are permitted. However, we
recommend against using them except in legacy situations (for example,
where such names are already in use in another security system).
• These strings cannot contain two adjacent space characters.

132
• The first and last characters must not be spaces.

• These strings must contain at least one non-space character.
• These strings cannot contain embedded newline characters (\n) or null
characters.
• The null or empty string is not a legal user name nor password.

Limiting Access 133
|
Limiting Access
A secure daemon controls user access to local communications. Administrators

can limit access at two levels of granularity:
• Network and service
• Subject
Network and Service Authorization

Each secure daemon allows its users to communicate over a set of local networks.
Two parameters together define a local network:
• Network Specification
For details, see Constructing the Network Parameter on page 23.
• UDP or PGM Service
For details, see Specifying the UDP or PGM Service on page 21.
You must explicitly authorize each local network by specifying these two
parameters. To authorize a local network, see Authorize Network and Service
Pairs on page 158.
Users can communicate only on the local networks that you authorize. A user
program cannot create a client transport that specifies an unauthorized local
network (the transport create call produces an error status code).
Default Local As an administrator, you can designate a default local network. A client transport
Network that does not specify particular network and service parameters automatically
communicates over this default local network; see Default Network and Service
on page 154.
Subject Authorization
Each secure daemon allows its users to communicate using a set of Rendezvous
subject names.
• Subjects authorized for sending can flow from client transports out to local
networks.
A client transport that sends a message with an unauthorized subject does not
receive any error indication; instead, the secure daemon silently discards the
message.

134
• Subjects authorized for listening can flow to client transports from local
networks.
A client transport that creates a listener with an unauthorized subject does not
receive any error indication—but the resulting listener object never receives
any messages.
Subject authorization applies equally to all users and all local networks.
All _INBOX subjects are implicitly authorized. It is not necessary to explicitly
authorize _INBOX subjects.
To authorize secure daemon subjects, see Authorize Subjects on page 159.
If clients use fault tolerance, certified message delivery, or distributed queue

features, you must authorize the appropriate administrative subjects; see these
tables:
• Critical Subjects for Certified Delivery on page 278
• Critical Subjects for Fault Tolerance on page 283
• Critical Subjects for Distributed Queues on page 286

Security Factors 135
|
Security Factors
Store Files
The secure daemon store file contains very sensitive information. Store it on the
local file system of the secure daemon’s host computer, with tight file access, in a
physically secure environment. Ensure timely backup to secure media.
Core-Dump Files
Secure daemon process storage contains sensitive information in unencrypted

form. Similarly, user program storage can contain passwords or private key data.
It is essential to deny access to these processes and their core image files. We
strongly recommend arranging operating system parameters to prevent creation
of core files.
To guard against attacks, take these precautions:
• Configure the operating environment to avoid making core dumps.
• Configure the operating environment to prevent access to process memory (if
possible).
• Ensure that file system storage is secure.
Daemon Certificates
Administrators must implement a secure mechanism to distribute the secure

daemon’s public certificate to users (that is, either programmers of client
programs or end users).
Ensure that users verify daemon certificates before using them with client
programs. Ensure that users keep daemon certificates in files that a secure from
unauthorized modification or tampering. Remember, a false certificate can give a
rogue daemon access to user passwords.

136
Passwords
Private key files use password-encryption for security. Nonetheless, these files are
important points of vulnerability.
To guard against attacks, ensure that file system storage is secure, and keep all
passwords secure.
• Do not store passwords in non-secure files or on non-secure file systems.
• Control access to sensitive files—even when those files are
password-encrypted.
• Never hard-code passwords in application programs, nor accept them as
command line parameters.
• Code programs to erase passwords from process storage before exiting.
• Never write passwords in convenient locations.
• Never send passwords in plaintext messages.
• Choose passwords carefully.

Behavioral Differences 137
|
Behavioral Differences
Secure daemons exhibit slight differences in behavior from their non-secure

counterparts. This section summarizes those differences.
Automatic Start and Stop

rvdcan start either automatically or by explicit command. In contrast,
administrators must start rvsd by explicit command.
rvd can stop automatically after an interval in which it has no clients (see rvd on
page 36, and -no-permanent on page 38). In contrast, rvsd does not stop
automatically.
Subject Gating
Secure daemons are silent when subject gating parameters preclude send or listen
operations:
• Subjects authorized for sending can flow from client transports out to local
networks.
A client transport that sends a message with an unauthorized subject does not
receive any error indication; instead, the secure daemon silently discards the
message.
• Subjects authorized for listening can flow to client transports from local
networks.
A client transport that creates a listener with an unauthorized subject does not
receive any error indication—but the resulting listener object never receives
any messages.
Default Network and Service

Secure daemons and non-secure daemons behave differently when a client
transport specifies a default value (that is, null) for its network or service
parameter. Non-secure daemons use external defaults; see Specifying the UDP or
PGM Service on page 21 and Constructing the Network Parameter on page 23. In
contrast, secure daemons use internal defaults—which you can configure using
the browser administration interface; see Default Network and Service on
page 154.

138
Browser Connections
Secure daemons automatically open both HTTP and HTTPS ports for browser
administration interface connections—unless you specify otherwise. When an
HTTPS connection is available, the daemon uses it; that is, whenever possible, it
transfers non-secure HTTP communication over to its secure HTTPS connection.
You can block the secure HTTPS connection by specifying -http-only, which
leaves only the non-secure HTTP connection.
You can block all browser administration interface connections by specifying
-no-http.
See Also Network and Service Authorization on page 133

Default Network and Service on page 154

rvsd 139
|
rvsd
Command
Syntax rvsd -store <filename>

[-http-only]
[-no-http]
[-no-multicast]
[-foreground]
Purpose The command rvsd starts the Rendezvous secure communications daemon
process—the secure counterpart to rvd.
Remarks This section describes only those aspects where rvsd differs from rvd. For details
that both daemons share, see rvd on page 36.
Although rvd usually starts automatically, administrators must start rvsd by
explicit command.
(Sheet 1 of 3)
-store <filename> This file contains the security parameters that configure rvsd.
rvsd reads this file when the process starts, and writes this file
The secure daemon store file contains very sensitive
information. Store it on the local file system of the secure
daemon’s host computer, with tight file access, in a physically
secure environment. Ensure timely backup to secure media.

140
(Sheet 2 of 3)
-http <http_port>
-https <ip_address>:<https_port> To limit access to a browser on the rvsd host computer, specify
-https <https_port>
HTTP or HTTPS port.
exits.


and -https.

rvsd 141
|
(Sheet 3 of 3)
-listen <ip_address>:<ssl_port> rvsd (and by extension, rvsrd operating within the local
network) opens an SSL client socket to establish
-listen <ssl_port>
-listen parameter specifies the SSL port where the
client programs. This -listen parameter of the secure
daemon corresponds to the daemon parameter of the transport
creation call (they must specify the same SSL port number).
this daemon accepts SSL connections.
connections from any computer on the specified SSL port.
to accept connections from any computer on SSL port 7500.

parameter.
-reliability <time> These parameters are the same as for rvd.
-logfile <log_filename> For details, see Command Line Parameters on page 37.
-log-rotate <size>
-log-config <config_log_filename>
-foreground

142
rvsrd
Command
Syntax rvsrd -store <filename>

[-http-only]
[-no-http]
[-idle]
[-no-multicast]
[-foreground]
Purpose The command rvsrd starts the Rendezvous secure routing daemon process—the
secure counterpart to rvrd.
Remarks This section describes only those aspects where rvsrd differs from rvrd. For
details that both daemons share, see rvrd on page 92.
Administrators must start rvsrd by explicit command.
(Sheet 1 of 3)
-store <filename> This file contains the security parameters that configure rvsrd,
as well as the routing table entry and parameters that
configure its routing daemon behavior.
rvsrd reads this file when the process starts, and writes this
file each time you change the configuration using the browser
The secure daemon store file contains very sensitive
information. Store it on the local file system of the secure
daemon’s host computer, with tight file access, in a physically
secure environment. Ensure timely backup to secure media.

rvsrd 143
|
(Sheet 2 of 3)
-http <http_port>
-https <ip_address>:<https_port> To limit access to a browser on the rvsrd host computer,

specify 127.0.0.1 (the local host address).
-https <https_port>
HTTP or HTTPS port.
exits.


and -https.

144
(Sheet 3 of 3)
-listen <ip_address>:<ssl_port> rvsd (and by extension, rvsrd operating within the local
network) opens an SSL client socket to establish
-listen <ssl_port>
-listen parameter specifies the SSL port where the
client programs. This -listen parameter of the secure
daemon corresponds to the daemon parameter of the transport
creation call (they must specify the same SSL port number).
this daemon accepts SSL connections.
connections from any computer on the specified SSL port.
to accept connections from any computer on SSL port 7500.

parameter.
-idle These parameters are the same as for rvrd.

-reliability <time> For details, see Command Line Parameters on page 92.
-logfile <log_filename>
-log-rotate <size>
-log-config <config_log_filename>
-foreground

Browser Administration Interface—rvsd and rvsrd 145
|
Browser Administration Interface—rvsd and rvsrd
The browser administration interface lets you control rvsd and rvsrd from a web
browser. You can configure their operating parameters and view internal data
structures.
This section describes only those pages specific to the secure daemons. For
information about pages they share with their non-secure counterparts, see
Browser Administration Interface—rvd on page 45, and Browser Administration
Interface—rvrd on page 96.
Topics

• Daemon Parameters, page 152
• Users, page 156
• Authorize Network and Service Pairs, page 158
• Authorize Subjects, page 159
• Certificates, page 161

146
Navigation
Figure 35 rvsd Navigation Panel

Navigation 147
|
Figure 36 rvsrd Navigation Panel

148
(Sheet 1 of 2)


page 50.
Local This page summarizes the local networks of a router; see Local
Networks Networks on page 101.
Connected This page summarizes the actual neighbor connections of a

Neighbors router; see Connected Neighbors on page 103.

on page 52.

Navigation 149
|
(Sheet 2 of 2)

Configuration Daemon This page lets you configure parameters that control
Parameters configuration access and secure default values for service and
network parameters; see Daemon Parameters on page 152.
For rvsrd, this page also configures router logging; see
Logging on page 110.
Routers This page lets you configure routers. You can access additional
configuration pages through links on this page. See Routers on
page 111, and the sections that follow it.
XML This page lets you view the current configuration as an XML
Configuration document, and reconfigure the component by submitting an
edited XML document.
Users These pages let you register authorized users; see Users on
page 156.
Networks and This page lets you configure the network and service pairs that
Services client transports can use for Rendezvous communication; see
Authorize Network and Service Pairs on page 158.
Subjects This page lets you configure the subjects that client transports
of a secure daemon can use for sending or listening; see
Authorize Subjects on page 159.
Certificates This page lets you configure certificates that the daemon uses
to identify itself in secure protocols. See Certificates on
page 123.
Log Out This item logs out the current user or administrator. See Log
Out on page 110.

Rendezvous
Web Page

150
General Information
rvsd and rvsrd (like all Rendezvous components) display information about
themselves on this page.
the secure daemon browser administration interface.
Figure 37 rvsd General Information Page
(Sheet 1 of 2)
Item Description
component The name of the program—rvsd or rvsrd.
client port The SSL port where the daemon listens for client connections.

|
(Sheet 2 of 2)
Item Description
services
store file File name of the daemon’s store file; see the command line parameter -store for
rvsd on page 139, and for rvsrd on page 142.

152
Daemon Parameters
This page lets you configure parameters that affect overall daemon security.
To display this page, click Daemon Parameters in the left margin of any page of
the secure daemon browser administration interface.
For rvsd, this page contains two areas—Administrator and Password panel, and
a Default Network and Service panel. For rvsrd, this page adds a third panel for
logging parameters; see Logging on page 110.
Administrator and Password

Figure 38 Secure Daemon Administrator and Password Area
Only authorized personnel have administrative access to secure daemons. (In

contrast, to configure client program user names, see Users on page 131.)
When administrator identification information is not set, anyone who can connect
to the browser administration interface can examine and reconfigure the daemon.
This arrangement can be useful during initial configuration and testing phases.
However, during regular operation we recommend limiting access.

|
Once administrator identification information is registered, the browser

administration interface is locked against unauthorized access. The daemon
prompts administrators to prove identity by typing a name and password. After
providing proper identification, an authorized administrator is logged in, and has
complete access to configure the daemon. If the administrator does not provide
proper identification, the browser displays the General Information page and
continues to prompt for a correct name and password.
Browsers remember administrator name and password information for the

duration of the browser process. Merely closing the browser window does not
erase this information. To guard against intruders you must terminate the
browser process (all its windows).
Primary The first administrator to register is called the primary administrator. In addition to
Administrator configuring the daemon, the primary administrator can also add, delete and
modify identification information pertaining to the other administrators.
Each daemon configuration can store up to 16 additional administrator name and
password pairs (after the primary administrator).
One Each daemon process permits only one administrator session at a time. When one
Administrator administrator is logged in, other administrators are locked out; this prevents
Session conflicts in which two administrators attempt to modify the configuration at the
same time. To terminate a administrator session, see Log Out (below).
(Sheet 1 of 2)
Item Description
Name Type a name string.
Password Type a password string.
Confirm Password Type the password again.
Add/Update Specify a name and password, then click this button to

add a new user.
administrator.

154
(Sheet 2 of 2)
Item Description
Delete Click this button to delete administrator identification
information.
administrator.
Deleting the primary administrator also deletes all
other administrators.
Log Out
To end an administrative session, click Log Out in the left margin of the browser
administration interface. This item appears only when you are logged in as an
Administrator.
Daemons automatically log out administrator sessions that have been idle for 10
minutes.
Default Network and Service

Figure 39 Secure Daemon Default Network and Service

|
Secure daemons and non-secure daemons behave differently when a client

transport specifies a default value for its network or service parameter.
Non-secure daemons use external defaults; see Specifying the UDP or PGM
Service on page 21 and Constructing the Network Parameter on page 23. In
contrast, secure daemons use internal defaults—which you can configure using
this panel.
Unless you explicitly set values for these default parameters, they remain null—
indicating the absence of any default value.
When either default is absent, the secure daemon will refuse connections from
programs that rely on the default. As a result the transport creation call in the
program fails.
For background information, see Network and Service Authorization on

page 133.
Item Description
Network Type the default network.
Service Type the default UDP or PGM service.
See Also Default Network and Service on page 137

156
Users
This page lets you configure the set of users that can connect to a secure daemon.
(In contrast, to configure administrative users, see Administrator and Password
on page 152.)
To display this page, click Users in the left margin of any page of the secure
daemon browser administration interface.
For background information, see Users on page 131.
Figure 40 Secure Daemon Users Page

Users 157
|
Add a New User

This panel lets you create new users.
Item Description
User Name Required. Every user must have a unique name, distinct from every
other user that this secure daemon administers.
For syntax rules governing user names, see User Name and Password
Identification on page 131.
To add a user, type the user name, and click the Add User button.
Existing Users
This list displays the users currently authorized to connect to the secure daemon.
Buttons operate on selected users from the list.
Button Description
Password Displays a page that lets you view and set the password for the selected
user.
Certificates Displays a series of pages that let you view and set public certificates for
the selected user.
Remove Selected Deletes one or more selected users from the list.
Users

158
Authorize Network and Service Pairs
This page lets you configure the network and service pairs that users can access
through the secure daemon.
To display this page, click Networks and Services in the left margin of any page
of the secure daemon browser administration interface.
Figure 41 Secure Daemon Authorize Network and Service Pairs Page
Item Description
Network & This table lists the pairs of network and service that all authenticated
Service Pairs users may access through this secure daemon.
To remove a pair from this list, click to check its Select box, then click the
Remove Selected Network & Service Pairs button.
Add To add access to a network and service pair, type the specifications and
click the Add button.

Authorize Subjects 159
|
Authorize Subjects
This page lets you configure the Rendezvous subjects that users can access
through the secure daemon.
To display this page, click Subjects in the left margin of any page of the secure
daemon browser administration interface.
For background information, see Subject Authorization on page 133.
Figure 42 Secure Daemon Authorize Subjects Page
_INBOX subjects are implicitly authorized both for listening and sending. You do
not need to authorize them explicitly on this page.
(Sheet 1 of 2)
Item Description
Authorized to Listen This table lists subjects to which authenticated users may subscribe.
Authorized to Send This table lists subjects to which authenticated users may send messages.

160
(Sheet 2 of 2)
Item Description
Remove Selected To remove authorization for particular subjects, select the affected subjects
Subjects and click this button.
Subject To add access to a subject, type the subject here and click one of three
buttons:
• Authorize to Listen
• Authorize to Send
• Authorize to Listen and Send

Certificates 161
|
Certificates
This page lets you configure the X.509 certificates that a secure daemon uses to
identify itself.
To display this page, click Certificates in the left margin of any page of the rvrd
For background information, see Certificates and Security on page 53 in TIBCO
Each daemon process keeps a list of certificates it can use to identify itself. These
certificates are numbered for easy reference. The first panel on this page
determines which of these certificates the daemon uses for particular tasks. The
remainder of the page lets you enter the certificates.
Certificate Uses
Figure 43 rvsrd Certificate Uses Form
(Sheet 1 of 2)
Item Description
HTTPS Set the certificate for the secure browser administration interface.
To avoid security warnings from the web browser, distribute the public portion of
this certificate to authorized administrators.

162
(Sheet 2 of 2)
Item Description
Routers to Set the certificate for secure SSL neighbor connections.
Routers
Distribute the public portion of this certificate to each applicable neighbor.
(This item is included in routing daemons only; it is absent from rvsd.)
Daemon to Set the certificate for secure SSL client transport connections.
Clients
Distribute the public portion of this certificate to each client program; see Secure
Daemon on page 60 in TIBCO Rendezvous Concepts.

Certificates 163
|
Certificate List
Figure 44 rvsrd Certificate List

164
Item Description
certificate Use this number to refer to the certificate in the Certificate Uses panel.
number
Add from Enter a file name and a private key password. When you click Add from File, the
File daemon reads the certificate with private key from the file. The file may be in either
PEM encoding, or PKCS #12 format.
Add from Paste the text of a certificate with private key. Enter a private key password.
Text
The certificate must be in PEM encoding.
Self-Signed When the daemon creates its store file (the first time it starts), it also creates a
Certificate self-signed certificate, and registers it in the list as certificate #1. You may use that
certificate as is, add other certificates to the list, or delete it and enter other
certificates.

| 165
Chapter 7 Relay Agent
Relay agents support certified delivery in situations where persistent

correspondents connect only intermittently to the network.
For example, many enterprises use laptop computers, which operate
independently for extended periods and reconnect to the network when it is
convenient. As another example, consider a persistent correspondent that runs as
an ephemeral process; at regular intervals a UNIX cron job starts the process,
which sends several certified messages and then exits. Relay agents support
certified message delivery in situations like these.
Topics
• rvrad, page 166
See Also
Certified Message Delivery on page 139 in TIBCO Rendezvous Concepts
Relay Agent on page 169 in TIBCO Rendezvous Concepts

166
| Relay Agent
rvrad
Command
Syntax rvrad -name <name>

-store <filename>
[-service <service>]
[-network <network>]
[-daemon <daemon>]
Purpose The command rvrad starts a Rendezvous relay agent process. The relay agent is a
process that stores certified messages (and associated protocol messages) for
program processes that connect to the network intermittently. For an overview,
see Relay Agent on page 169 in TIBCO Rendezvous Concepts.
Remarks System administrators must start relay agent (rvrad) processes explicitly, and
keep it running at all times. That is, the relay agent must be running whenever
disconnected program processes reconnect to the network, and must remain
running continuously to collect inbound messages on behalf of their client
programs.
A relay agent process requires resources in proportion to the number of certified
delivery client programs that it serves.
From the perspective of the Rendezvous daemon (rvd), the relay agent process
(rvrad) behaves exactly like any other Rendezvous program. The relay agent’s
-service, -network and -daemon parameters are completely analogous to the
corresponding parameters of the transport creation call; rvrad uses these values
to create a transport that it uses to communicate both with certified delivery client
programs and with other relay agents.
When relay agents or their client programs operate across routing daemons, see
Forward RVCM Administrative Messages across Network Boundaries on
page 278.
On UNIX computers, the relay agent runs as a background process.
The relay agent does not use a browser administration interface.

rvrad 167
|
(Sheet 1 of 2)
-name <name> Bind this reusable name to the relay agent process.
CM transports designate and locate their relay agents by name.
Relay agent names must be unique. It is illegal to run two or more relay
agents with the same name simultaneously. It is illegal for a relay agent to
have the same name as a CM correspondent.
We strongly discourage using the empty string as a relay agent name.
The name must conform to the syntax rules for reusable names. For details,
see Reusable Names on page 166 in TIBCO Rendezvous Concepts.
-store <filename> Use this file to store relay agent state.

The argument must represent a valid file name. Actual locations
corresponding to relative file names conform to operating system
conventions.
The relay agent synchronizes the file to disk on a periodic schedule.
-service <service> The relay agent creates a transport on this service, which it uses to
communicate both with its clients and with other relay agents. Clients that
communicate with this relay agent must use the same service and network.
You can specify the service in several ways. For details, see Service
Selection on page 20.
NULL specifies the default rendezvous service.
-network <network> On computers with more than one network interface, the -network
parameter instructs the Rendezvous daemon to use a particular network
for communications involving this transport.
The relay agent creates a transport on this network, which it uses to
communicate both with its certified delivery client programs and with
other relay agents. Clients that communicate with this relay agent must
use the same service and network.
You can specify the network in several ways. For details, see Constructing
the Network Parameter on page 23.
NULL specifies the primary network interface for the host computer.

168
| Relay Agent
(Sheet 2 of 2)
-daemon <daemon> The -daemon parameter instructs rvrad about how and where to find rvd
and establish communication. The value of the rvrad -daemon parameter
must match the rvd -listen parameter.
For details, see Daemon Client Socket—Establishing Connections on
page 28.
You can specify a daemon on a remote computer. For details, see Remote
Daemon on page 29. However, rvrad cannot start a remote rvd
automatically; it must be already running on the remote computer.
If -daemon is not present, rvrad finds the local daemon on TCP socket
7500.
See Also Forward RVCM Administrative Messages across Network Boundaries, page 278.
Relay Agent on page 169 in TIBCO Rendezvous Concepts.

| 169
Chapter 8 Rendezvous Agent (rva)
The Rendezvous agent (rva) is a background process that supports Rendezvous

communications for Java applets. For security reasons, remote untrusted applets
cannot connect directly to the Rendezvous daemon (rvd); instead, they connect to
rva, which in turn connects to rvd.
The Rendezvous agent protects the Rendezvous daemon from inappropriate

requests. It acts as security barrier, protecting the Rendezvous network against
interference.
Remote Java applets cannot start an rva process; instead, they must connect to an
agent process that is already running. Network and system administrators must
ensure that an appropriate agent process is running at the web server host
computer, so applets can connect back to it.
Topics
• rva, page 170

• Web Site Considerations, page 177

170
| Rendezvous Agent (rva)
rva
Command
Syntax rva -store <filename>

[-http-only]
[-no-http]
[-idle]
[-foreground]
Purpose The command rva starts the Rendezvous agent process. The Rendezvous agent is
the gateway to the Rendezvous network for remote Java applets.
Remarks Usually, administrators must start the Rendezvous agent (rva) process explicitly.
A Java applet cannot start rva; an applet must connect to an agent that is already
running.
From the perspective of the Rendezvous daemon (rvd), the agent process (rva)
behaves exactly like any other Rendezvous program. The agent’s Service,
Network and Daemon parameters are completely analogous to the corresponding
parameters of the transport creation call (because rva uses these values to create a
transport). In turn, the transport creation call uses these parameters to find or
start an appropriate daemon and connect to it.
Licenses Each rva process instance reads the license ticket file (tibrv.tkt) when it starts.
To put new license tickets into effect, stop and restart rva.
If rvd is not running, then rva starts it automatically, and the new rvd process
instance requires a valid rvd license (in addition to the rva license).
Subject Gating For fine-grained control over all the information flowing in or out of your
networks, limit communication by subject name.
The Import and Export parameters let system administrators restrict the flow of
messages through rva based on subject names.
Point-to-point messages (_INBOX.>) always pass through rva. They are not
restricted by subject gating parameters.
For information about restricting with wildcard subjects, see Subject Filtering
with Wildcards on page 67.
In release 6 (and later), the default behavior for rva subject gating is to restrict all
subjects unless permitted by subject gating parameters.
In earlier releases, when gating parameters were not specified, the default
behavior was to permit all subjects for import and export.

rva 171
|
Maximum rva supports approximately 4000 clients through TCP connections, or
Clients approximately 1500 clients through HTTP connections. These limits are not
additive.
Lower file descriptor limits can further reduce the maximum number of rva clients
(see File Descriptor Limits on page 9).
(Sheet 1 of 2)
-store <filename> This file contains the parameters that configure rva.
rva reads this file when the process starts, and writes this file
-http <ip_address>:<http_port> The browser administration interface accepts connections on this

HTTP or HTTPS port. Permit administration access only through
-http <http_port>
the network interface specified by this IP address.
-https <https_port>
When the IP address is absent, the daemon accepts connections
through any network interface on the specified HTTP or HTTPS
port.
exits.
HTTP and HTTPS ports where it accepts browser administration
interface connections.


172
(Sheet 2 of 2)
-no-http Disable all HTTP and HTTPS connections, overriding -http and
-https.
-idle When present, start rva in its idle state.

When absent, start rva in its running state—serving Java clients.
You can toggle the state at any time using the browser

Log file rotation is not available for rva.

If present, rva runs as a foreground process.
If not present, rva runs as a background process.
Browser Administration Interface
(Sheet 1 of 5)
State
State Toggle between idle and running.

When running, rva accepts connections from Java client programs, and
permits network communication access on behalf of those client programs.
When idle, rva disconnects all Java client programs, and bars any new
connections.

rva 173
|
(Sheet 2 of 5)
Network Connections
Listen Port The Rendezvous agent creates a TCP socket to establish communication
between itself and its Java clients. This parameter specifies the TCP port
where the agent listens for client connect requests. This port number
corresponds to the port parameter of the Java TibrvRvaTransport()
constructor (they must specify the same TCP socket number).
The default TCP port is 7600—corresponding to the default port that
TibrvRvaTransport() uses.
Service When rva communicates on behalf of its Java clients, it communicates on

this UDP or PGM service. As a result, the Java clients can communicate
only with other programs that create transports in this service group.
The Rendezvous agent uses this parameter to connect to the Rendezvous
daemon. This parameter is analogous to the service parameter of the
transport creation call.
Each rva process can communicate on only one service. To communicate
over more than one service, you must start additional rva processes.
You can specify the service in several ways. For details, see Service
Selection on page 20.
Network On computers with more than one network interface, this parameter
instructs the Rendezvous daemon to use a particular network for all
communications involving this transport.
The Rendezvous agent uses this parameter to connect to the Rendezvous
daemon. This parameter is analogous to the network parameter of the
transport creation call.
Each rva process can send outbound broadcast messages to only one
network. To communicate over more than one network, you must start
additional rva processes.
You can specify the network in several ways. For details, see Constructing
the Network Parameter on page 23.

174
(Sheet 3 of 5)
Daemon This parameter instructs rva to find rvd and establish communication on a
specific TCP port. The value of this rva daemon parameter must match the
rvd listen parameter.
For details, see Daemon Client Socket—Establishing Connections on

page 28.
Daemon on page 29. However, rva cannot start a remote daemon
automatically—you must start it manually on the remote computer.
With the default value, rva finds the local daemon on TCP port 7500.
Subject Gating
Imported Subjects rva imports messages from clients (applets) to the network.
Only messages with subject names that match these subject names are
eligible for import.
You can remove a subject at any time.
Exported Subjects rva exports messages from the network to clients (applets).
Only messages with subject names that match these subject names are
eligible for export.
You can remove a subject at any time.
HTTP Tunnel
See also HTTP Tunnel on page 180.
Enable When enabled, rva accepts HTTP connections from client transports. To
enable HTTP tunneling, check this box.
Port rva accepts HTTP connections from client transports on this this port.
Client Timeout In some situations, rva closes HTTP connections to flush data to clients
through intervening proxy servers. Each client transport subsequently
reestablishes its connection after a delay (specified in the client program).
Meanwhile, rva maintains state information for the client. If this timeout
expires before the client reconnects, rva can discard the state information.
Ensure that this parameter (in seconds) is much greater than the reconnect
delay parameter of every client transport.

rva 175
|
(Sheet 4 of 5)
Ping Interval Intervening proxy servers might automatically close client connections to
rva that appear inactive. To circumvent this feature, rva sends ping
messages to clients when a connection has been idle for this interval (in
seconds).
To disable this feature, supply zero.
Max Client Queue rva limits the length of the data queue for each client (data is outbound
from rva, inbound to the client). When a queue exceeds this number of
messages, rva discards subsequent messages as they arrive.
Max Queue Size rva limits the size of the data queue for each client (data is outbound from
rva, inbound to the client). When a queue exceeds this size (in kilobytes),
rva discards subsequent messages as they arrive.
Active Flush This parameter limits data latency (in seconds) caused by buffering in
intervening proxy servers. If rva has directed data to a client, and this time
limit has elapsed since rva last flushed the data, then rva closes the
connection to force proxy servers to deliver the data to the client. This
action occurs even when rva has more data queued for the client (that is,
the queue is active).
If you are certain that no proxy servers intervene between rva and the
client, set this parameter to zero.
Inactive Flush This parameter limits data latency (in seconds) caused by buffering in
intervening proxy servers. If rva has directed data to a client, and does not
have more data queued for the client (that is, the queue is inactive), and
this time limit has elapsed since rva last directed data to the client, then
rva closes the connection to force proxy servers to deliver the data to the
client.
Request Flush This parameter limits data latency (in seconds) for reply messages. In some
application domains, the client sends a request message, and receives only
one small reply message. Setting this parameter smaller than
inactiveFlush can expedites delivery of such reply messages to the
client.

176
(Sheet 5 of 5)
Max Proxy Buffer This hint estimates the size (in kilobytes) of the largest buffer in
intervening proxy servers. Before triggering an active flush, rva checks the
amount of data it directed to the client since the last flush; if that amount is
greater than this value, the proxy server has probably flushed its buffer
automatically, so rva does not close the connection to flush the data.
Certificates
These parameters control the use of certificates as administrator credentials.
XML Configuration
View the current configuration as an XML document, and reconfigure the component by submitting
an edited XML document.
Security
These parameters control access to the configuration pages of the rva browser administration
interface.

Web Site Considerations 177
|
Web Site Considerations
The Rendezvous agent (rva) is a key component of any web site that distributes
Rendezvous applets. A full treatment of web site administration is beyond the
scope of this book; this section discusses issues specific to Rendezvous applets
and rva.
Home Computer and Port

Java applets connect back to an rva process on the web server host computer by
calling the constructor TibrvRvaTransport() with hostname and port
arguments. An rva process must be running on the web server host computer,
listening for client connections on a specific TCP port. Applet calls to
TibrvRvaTransport() must use a TCP port that matches the -listen parameter
of rva (both use 7600 as a default port number).
Administrators must inform applet developers of the TCP port where rva is
listening for applet connections, so applet code can supply it as an argument to
TibrvRvaTransport(). If you reconfigure rva to listen on a different port,
applets cannot connect until updated to the new port number.
Open a Path through the Firewall

Administrators must configure the firewall so that TCP connection requests can
propagate from the applet back to rva. Applets can only connect if this path is
open.
For example, Figure 45 on page 178 illustrates a double firewall configuration.
Applet connection requests travel on path A (TCP port 7600), and rva requests
connection to the remote rvd using path B (TCP port 7577). Both these paths must
be open.

178
Figure 45 Typical rva Web Site with Double Firewall
Physical
Software Hardware
Connections
Remote
Internet
Java Applet
External Computer
Applet
A
Download Hardware Router
Outer Firewall
Outer Firewall
Listen 7600
http Server
rva
Daemon
Web Server Host
Daemon 7577
Inner Firewall
B
Hardware Router
Inner Firewall
Listen 7577
Service 7901
rvd
Internal Computer
Internal Network
Information Bus
7901 Visible Local

rvd
Java Applet
Internal Computer
7854 Private Local

rvd
Java Applet
Internal Computer

Web Site Considerations 179
|
Isolate External from Internal

In the context of a web site with Rendezvous applets, it is especially important to
isolate separate pathways for various programs, to protect internal Rendezvous
application programs from external applets.
Techniques include using multicast addressing and restricting flow by subject.
For more information, see these sections:
• Network Details, page 17
• Subject Gating, page 170
For example, near the bottom of Figure 45 on page 178, rvd links external applets
with internal UDP or PGM service 7901. All internal Rendezvous programs that
use service 7901 can exchange messages with applets across the Internet. In
contrast, a private demonstration applet uses service 7854—it is effectively
isolated from the external applets, as well as from internal programs using service
7901.

180
HTTP Tunnel
Java programmers can specify HTTP tunneling for communication between a

client transport and rva. Administrators can configure rva parameters that affect
this type of communication.
This section describes the general operation of this feature, and the rva
parameters that affect it.
Overview For an overview of HTTP tunneling, see these sections:

• HTTP Tunneling on page 14 in TIBCO Rendezvous Java Reference
• TibrvRvaTransport on page 186 in TIBCO Rendezvous Java Reference
Operation When rva enables HTTP tunneling, it accepts client connection requests on an
HTTP port. Client transports connect to rva at that port.
rva maintains state information for each client, as well as a queue of data for the
client (data is outbound from rva, inbound to the client).
For efficiency, rva accumulates several messages in a queue before directing them
to a client.
HTTP proxy servers might intervene between rva and the client. Proxy servers
are usually transparent to both clients and rva. However, some intervening proxy
servers might buffer data at a low level, causing delays in data delivery to clients.
To limit data latency, rva can force proxy servers to flush their buffers by closing
the client connection; several parameters affect this flushing action. Client
transports automatically reestablish the connection, after a time delay specified in
the client program. rva maintains client state (for a limited time) while waiting
for the client to reconnect.
Parameters For a list of rva parameters that affect this feature, see HTTP Tunnel on page 174.

| 181
Chapter 9 Current Value Cache
In many distributed applications new processes can join the system at any time.
Often these new processes need access to the current information state of the
system in order to function properly. In many cases a straightforward cache
program can fill that need.
The Rendezvous distribution includes a utility program called rvcache, which
caches the data from messages sent to each subject name. Whenever a
Rendezvous program begins listening to a subject name, it can query rvcache to
send it the current data for that subject.
The data cached for a subject can be either the most recent whole message on that
subject, or a composite set containing the most recent value of each field sent on
that subject.
Although rvcache resembles a simple database program in some respects, it
differs in an important way. Namely, updates are implicit; that is, rvcache
monitors message activity and automatically caches the data. Application
components query for data by subject.
We recommend that administrators arrange for correct operation of rvcache. This
chapter describes administrative considerations; for a command summary, see
rvcache on page 189.
Topics
• Operation, page 182

• Resource Requirements, page 184
• Avoid Duplicates, page 185
• Ensure Continuous Service, page 186
• Crossing Network Boundaries, page 187
• Fault Tolerance, page 188
• rvcache, page 189

182
| Current Value Cache
Operation
Although many distributed system components may depend upon rvcache, its
caching operation remains transparent to them.
Other application programs do not send update messages specifically to rvcache.
Instead, rvcache listens for a set of subjects, silently receiving messages and
caching the most recent data on each subject as it arrives, as in Figure 46.
Figure 46 Transparent Caching by rvcache
rvcache
foo.bar value
A B C
foo.bar
Rendezvous
However, other application programs do send query requests to rvcache.

Figure 47 on page 183 illustrates this phase of rvcache operation:
1. rvcache listens to the subject _SNAP.> for query messages.
2. A program submits a query for the cached value of foo.bar by sending an
empty message to the subject _SNAP.foo.bar (more generally, build the
query subject on the template _SNAP.<cached_subject>).
3. rvcache receives the query, and extracts the cache subject from the query
subject name. It sends the cached value for that subject to the reply subject of
the query message.

Operation 183
|
Figure 47 Query and Response with rvcache
rvcache
foo.bar value
A New B C
2. Cached Value of foo.bar
1. Query for foo.bar _SNAP.foo.bar
Rendezvous

184
Resource Requirements
For fastest response, run rvcache on a computer with a light processing load.
The computer running rvcache must have sufficient memory and disk space to
hold the current data cache. The exact amount of required space varies in
proportion to the number of subjects cached and the size of the stored values.
In some cases, you may find it expedient to distribute the resource requirements
and the processing load among several computers. To achieve this goal, you can
run several process instances of rvcache on separate computers. However, it is
important that various process instances of rvcache cache disjoint sets of subjects
(see Avoid Duplicates on page 185).

Avoid Duplicates 185
|
Avoid Duplicates
Listening programs rarely profit from receiving duplicate copies of the current
data. To prevent duplicates, consider one of these strategies:
• Run exactly one rvcache service.
• Ensure that rvcache services store disjoint subject sets.
When two or more rvcache services store the same subjects, then duplicate
messages can result. It the subject sets do not overlap, then duplication cannot
occur.
• Segregate rvcache services by listening on different UDP or PGM services.
You can use different UDP or PGM services to isolate groups of program
processes so that members of each group receive Rendezvous messages
exclusively from other members of the same group. In such cases, configure a
separate instance of rvcache for each group by setting its service parameter to
match the UDP or PGM service used by group members. For more detail
about this parameter, see Service Selection on page 20.

186
Ensure Continuous Service
Interruptions in rvcache service can result in two undesirable consequences:

• Programs that query during the interruption do not receive the cached data.
• The cache does not record data from messages sent during the interruption.
Gaps in the cache persist after the interruption.
To minimize these effects, we recommend that system administrators consider

these strategies:
• Avoid interruptions whenever possible.
For example, shift rvcache (along with its disk file) to an alternate host
computer before scheduled downtime. Since rvcache is independent of the
computer on which it runs, switching hosts can be an effective remedy.
• Reduce the length of unavoidable interruptions.
Monitor the health of the rvcache process and its host computer. If any
problem prevents smooth operation, promptly correct the situation or shift
rvcache to an alternate host computer.
• Run rvcache as a fault-tolerant service.

For details, see Fault Tolerance on page 188.

Crossing Network Boundaries 187
|
Crossing Network Boundaries
When a network boundary separates rvcache from its client programs, and a
routing daemon (rvrd) connects them across that boundary, you must configure
rvrd to ensure correct operation of rvcache.
Cached Subjects
The routing daemons (on both sides of the neighbor link) must permit all the
cached subjects to flow from all senders to all rvcache processes.
Query Subjects
The rvrd configuration for exchanging query subjects depends on the
distribution of rvcache and its query clients.
• If each network runs one local cache process, with all the caches synchronized
(so they all contain the same data), then it is crucial that only one rvcache
process receive each query. The routing daemons must not import or export
_SNAP.> (the query subject).
• If only one network runs a cache process, and programs on other networks
query it across the network boundary, then the routing daemons must forward
_SNAP.> (the query subject) into the rvcache network. That is, rvrd must
import these query names into the rvcache network; rvrd must export these
query names from each query client network.

188
Fault Tolerance
Multiple process instances of rvcache can cooperate for fault-tolerant service.

Fault tolerance protects rvcache service against hardware failures, process
termination and segmentation of the local network.
In this configuration, two or more rvcache processes run on separate
computers—usually on separate network segments. All cooperating processes
listen for the same set of subjects, and store the current values of those subjects.
Only one process (called the primary active process) actively sends the current
values to new listeners. The remaining processes (called inactive backup processes)
are inactive—unless they detect that the primary active process has failed. If the
primary fails, one of the backup process activates in its place, restoring service
automatically.
These chapters describe fault tolerance concepts and parameters in detail:
• Fault Tolerance Concepts on page 195 in TIBCO Rendezvous Concepts.
• Fault Tolerance Programming on page 213 in TIBCO Rendezvous Concepts.
• Developing Fault-Tolerant Programs on page 227 in TIBCO Rendezvous
Concepts.
For administrative details, see Fault Tolerance on page 281.
Usage
To run rvcache as a fault-tolerant service, start two or more rvcache processes. It
is essential that all processes use identical parameters—with only one exception:
• The -store parameter specifies a file for persistent storage of the cache and
configuration parameters. Member processes must not share this file. Each
member must keep its own distinct cache file (we recommend storing it on a
local disk).
Duplicating the Cache State

To duplicate the cache state, copy the cache file (so each process starts with an
identical copy). Avoid file inconsistencies that can arise when copying the file
while rvcache is running.

rvcache 189
|
rvcache
Command
Syntax rvcache -store <filename>

[-http-only]
[-no-http]
[-idle]
[-sync <interval>]
Purpose The program rvcache stores data from recent messages, indexed by subject name,
and automatically sends the cached data to new listeners.
Remarks Given a set of one or more subject names, rvcache listens for messages addressed
to those subjects. Each time it receives such a message, it stores the message’s data
content.
When a client program queries for a cached subject, rvcache sends a reply
message with the current cached value.
Browser To administer or configure rvcache, view http://<rvcache_host>:<http_port> with

Administration a web browser. When the program starts, it prints the actual HTTP administration
Interface port.
State rvcache can run in either of two states—running or idle.

When running, rvcache listens to subjects, caches message values, and responds
to queries.
When idle, rvcache does not operate; however, the browser administration
interface is available for configuring parameters.
Initial Subject The first time you run rvcache, you must configure its subjects and change its
Configuration state to running. After that, rvcache reads the subject list from its file.
Replace or rvcache stores message data in either of two ways. For each subject, it can either
Merge replace all previously stored data with the contents of each new message, or it can
merge information from the fields of the message into the stored data, overwriting
only those fields specified in the new message. Select one of these storage
methods each time you add a subject.
Data stored in rvcache never expires. It remains in the cache until superseded or
augmented by data from a new message on the same subject.

190
Storage rvcache stores the data in program memory and in a disk file. The command line
parameter -store specifies the name of the disk file; if the file exists when
rvcache starts, then rvcache reads the file to initialize its configuration
parameters and to populate its cache in process memory.
The command line parameter -sync specifies the interval at which to synchronize
the file-based store with process-based store.
(Sheet 1 of 2)
-store <filename> Use <filename> to record parameter configuration and for
persistent cache storage. For best performance, use a local file
system (remote file servers can cause delays and
synchronization difficulties).
For more information, see Storage on page 190.
-http <ip_address>:<http_port> The browser administration interface accepts connections on this

HTTP or HTTPS port. Permit administration access only through
-http <http_port>
the network interface specified by this IP address.
-https <https_port>
When the IP address is absent, the daemon accepts connections
through any network interface on the specified HTTP or HTTPS
port.
exits.
HTTP and HTTPS ports where it accepts browser administration
interface connections.

rvcache 191
|
(Sheet 2 of 2)
-no-http Disable all HTTP and HTTPS connections, overriding -http and
-https.
-idle When present, start rvcache in its idle state.

When absent, start rvcache in its running state—caching values
and responding to queries. However, if subjects are not
configured, rvcache begins in its idle state.
You can toggle the state at any time using the browser
-sync <interval> Request that the operating system synchronize the file system at
this interval (in seconds).
When this parameter is absent, the default is synchronize the file
system after every message that changes the store.
Browser Administration Interface
(Sheet 1 of 3)
information
This page displays general information about the rvcache process.
change state
State Toggle between idle and running.

When running, rvcache listens to its cache subjects, caches values, and responds
to queries.
When idle, rvcache does not operate; however, the browser administration
interface is available for configuring parameters.
The program does not store this parameter.

192
(Sheet 2 of 3)
certificates
This page lets you configure the certificates that rvcache uses to identify itself to web browsers. For
more information, see the analogous section for secure daemons, Certificates on page 161.
security
These parameters control access to the configuration pages of the rvcache browser administration
interface.
connection
rvcache uses these parameters to create its network transport object.
For general explanations, see Chapter 3, Network Details, on page 17.
Service See Service Selection on page 20.
Network See Network Selection on page 23.
Daemon See Daemon Client Socket—Establishing Connections on page 28.
fault tolerance
Enable Enable or disable fault-tolerant operation.

The remaining parameters in this group apply only when fault tolerance is
enabled.
Service Use this UDP or PGM service for fault tolerance control messages between
rvcache member processes.
The default value is rendezvous-ft; if the operating system cannot interpret that
service name, then the secondary default is UDP or PGM port 7504.
Network Use this network for fault tolerance control messages between rvcache member
processes.
The default value is the computer’s primary network interface.
Group Use this string as the name of the rvcache fault tolerance group.
Processes with the same group name cooperate to provide fault-tolerant service.
The default value is RVCACHE.

rvcache 193
|
(Sheet 3 of 3)
Weight Set the weight of this rvcache process.
Weight specifies relative precedence between fault-tolerant processes. A process
with greater weight takes precedence over a process with lesser weight.
The default value is 10.
Heartbeat Use this floating point value (in seconds) as the fault tolerance heartbeat interval.
Members of a fault tolerance group send status reports at this interval. We
recommend that this value be slightly less than one third of the activation
interval.
The default value is 3 seconds.
Activation Use this floating point value (in seconds) as the fault tolerance activation interval.
This value represents the longest interruption in service before the partner
process activates. It must be the same for all members of a fault tolerance group.
The default value is 10 seconds.
subjects
Subjects To see information about a specific subject, click that subject in the current subject
list.
You can add new subjects or remove current subjects at any time.
For more information, see Replace or Merge on page 189.
XML Configure
View the current configuration as an XML document, and reconfigure the component by submitting
an edited XML document.

194

| 195
Chapter 10 Performance Assessment (rvperf)
Performance assessment software can help you gauge and improve Rendezvous
network performance, plan hardware purchases and software deployment, and
test network configurations.
Topics
• Overview, page 196

• Principles of Operation, page 197
• Single Mode and Automatic Mode, page 198
• Automatic Mode—Binary Search, page 199
• Dataloss Advisory, page 200
• Multicast, Broadcast, Point-to-Point and Direct, page 201
• Before You Test, page 202
• rvperfm, page 204
• rvperfs, page 209
• Interpreting the Report, page 212
• Usage and Examples, page 216
• Hardware Capabilities, page 217
• Wide Area Networks, page 219
• Certified Message Delivery, page 220
• Very Large Messages, page 221
• Sufficiency and Effects, page 222
• Locating Performance Obstacles, page 223

196
| Performance Assessment (rvperf)
Overview
Rendezvous performance assessment software is a tool for evaluators, reviewers,

and network administrators. It measures the potential performance of
Rendezvous software in an actual network situation, and outputs a detailed
report.
This performance assessment software helps you compare various equipment
options and network configurations, using the performance of Rendezvous
software as a gauge.
Remember that speed benchmarks are relevant only in the context of a specific
network with specific computers. Networks can differ widely in their
performance. Adding or removing a problematic computer can dramatically alter
performance.
Rendezvous benchmark data is not a guarantee of application performance. It
demonstrates the potential maximum performance that your network can
achieve. Although it can model common application behaviors regarding
message sending and receiving, it cannot exactly mimic the actual performance of
your Rendezvous applications. The performance assessment tool stresses
message transport capabilities, but does not engage in other common application
behaviors, such as calculations or managing a graphics display.
The performance assessment tool can establish an upper bound on application
message transport performance, and help gauge some of the secondary effects of
network usage patterns, but it cannot prove that an application as a whole will
operate properly.
Components
Performance assessment software consists of two executable programs:
• rvperfm (master) sends messages, gathers performance data, and outputs the
report.
See rvperfm on page 204.
• rvperfs (slave) subscribes to messages from rvperfm, and sends back data
about its own speed and effectiveness.
See rvperfs on page 209.
You can run rvperfm alone, or with any number of rvperfs processes in the
network.

Principles of Operation 197
|
Principles of Operation
In our experience, Rendezvous distributed applications achieve optimal network

performance when senders transmit messages in short batches, pausing briefly
between batches. This observation is the foundation for the performance
assessment tool.
Performance assessment software measures network performance by sending
runs of messages, and compiling statistics. You can experiment by varying
parameters such as message size, run length, batch size, pause interval—which
affect the network data rate.
Each message contains s bytes of payload data (plus message headers and packet
overhead).
rvperfm sends one or more sequences (or runs) of m messages to the network.
Instead of sending a continuous stream of messages, rvperfm groups them into
batches of b messages, pausing for an interval of i seconds between the end of one
batch and the start of the next batch.
While rvperfm is sending messages, zero or more process instances of rvperfs
are listening for those messages and compiling statistics. At the end of each run,
the rvperfs processes report back to rvperfm, which outputs the statistics.
Listeners
rvperfm can send messages to the network whether or not any rvperfs processes
are listening to receive those messages.
• When rvperfs listeners are present, the performance assessment tool
measures their capacity to receive messages as part of overall network
performance.
• In the absence of rvperfs listeners, the performance assessment tool
measures the network performance of the sending computer only.

198
Single Mode and Automatic Mode
Two modes characterize the operation of rvperfm:

• In single mode, rvperfm sends a single run of messages, governed by its
command parameters. At the end of the run, it outputs a report and exits.
You can use single mode as a modeling tool to answer questions about
network behavior under sustained load conditions. For example:
— What happens to network performance when an application sends a batch
of ten thousand messages without pausing?
— Which computers in my network can send messages the fastest? Which can
receive fastest?
— How does introducing a router affect network throughput under normal
network load conditions? How do peak loads affect network throughput?
• In automatic mode, rvperfm sends several runs of messages, modifying the
parameters for each run until it finds the batch size and interval parameters
that yield maximum sustainable network throughput. At the end of each run,
it outputs a report. Then it adjusts the parameters and starts the next run.
The overall effect is that rvperfm tunes its send rate to match the maximum
receive rate of the slowest rvperfs process. The last report before the process
exits displays the parameters that yield the maximum throughput. (In the
absence of rvperfs processes, rvperfm determines the maximum send rate
that the network can support. Note that the parameter tuning algorithm is the
same, only the significance of the result differs.)
You can use the results of testing in automatic mode to tune applications for
maximum performance in a specific network configuration.

Automatic Mode—Binary Search 199
|
Automatic Mode—Binary Search
In automatic mode, rvperfm uses a binary search algorithm to adjust its batch size
and interval parameters between runs. These rules control rvperfm as it
empirically determines the maximum throughput:
• For the first run, rvperfm determines the batch size and interval from
command parameters or default values.
• If rvperfm loses data, it aborts the run immediately, and adjusts parameters to
decrease the send rate for the next run.
• If even one of the rvperfs processes lost data during the run, then the send
rate exceeds the maximum network throughput. In this case, rvperfm aborts
the run, records the upper bound on maximum throughput, and adjusts the
parameters to decrease the send rate for the next run.
• If all active rvperfs processes keep pace without lagging behind, and receive
all the messages without losing data—then the send rate is lower than the
maximum throughput. In this case, rvperfm records the lower bound on
maximum throughput, and adjusts the parameters to increase the send rate
for the next run.
• After a finite number of runs, the upper and lower bounds converge at the
maximum throughput. When rvperfm exits, the report of the last run
indicates the batch size and interval parameters that yield the maximum
network throughput.
If no rvperfs processes are active, the parameters of the last run yield the
maximum send rate for rvperfm on its host computer (with the prevailing
network conditions).

200
Dataloss Advisory
rvperfm and rvperfs both subscribe to DATALOSS advisories. At the end of each
complete run, both programs report the number of advisories they received
during the run.
If rvperfm receives a DATALOSS advisory, it aborts the run immediately. (This
paragraph applies only to automatic mode; if rvperfs receives a DATALOSS
advisory while rvperfm is in single mode, the run does not abort.)
If rvperfs receives a DATALOSS advisory, while receiving messages from rvperfm
in automatic mode, then rvperfs informs rvperfm in its response to the next auto
window poll, and rvperfm aborts the run. (This paragraph applies only to
automatic mode; if rvperfs receives a DATALOSS advisory while rvperfm is in
single mode, the run does not abort.)
See also, DATALOSS on page 249, TIBCO Rendezvous Concepts.

Multicast, Broadcast, Point-to-Point and Direct 201
|
Multicast, Broadcast, Point-to-Point and Direct
Rendezvous can transport messages among application programs using several

mechanisms. The performance assessment tool can model the performance of an
application sending messages in any of these ways:
Transport Modelling Notes

Multicast Specify multicast addressing in the -network parameter.
Omit the -inbox parameter.
Broadcast Do not specify multicast addressing in the -network parameter. TRDP only
Omit the -inbox parameter.
Point-to-Point Include the -inbox parameter.
Direct Specify a two part -service parameter to enable direct

Point-to-Point communication (bypassing rvd).
Include the -inbox parameter.
Performance The various transport mechanisms can display dramatically different

Characteristics performance profiles, which group into two broad classes.
Transport Description and Performance Characteristics

Multicast; Multicast and broadcast messages use an unmetered protocol with negative
acknowledgment. A sender transmits packets as fast as possible. Receivers are
Broadcast responsible for requesting retransmission of missed packets.
Many applications can gain efficiency by dividing very large multicast or
broadcast messages into smaller pieces, sending them in batches, and pausing
between batches to avoid overloading slow receivers (that is, receivers running
on relatively slow computers).
Point-to-Point; Point-to-point messages use a metered protocol with positive acknowledgment.

A sender requires positive acknowledgment from the receiver before it transmits
Direct additional point-to-point packets.
Point-to-Point
As a result, point-to-point packets (from a single sender) rarely arrive faster than
a receiver can process them. Applications generally do not gain efficiency by
dividing very large point-to-point messages into smaller pieces (since the
protocol itself already meters delivery).

202
Before You Test
Before running Rendezvous performance assessment software, read this section

carefully.
Test in an Insulated Environment

We strongly recommend that you run all performance tests in a network
environment that is insulated from other Rendezvous applications and other
network traffic.
Consider these two important benefits of an insulated environment:
• Insulation prevents performance assessment message traffic from disrupting
deployed applications.
• Insulation ensures that traffic from other applications does not skew
performance measurements.
Testing in a physically isolated network yields the most accurate measurements.

When physical isolation is impractical, you can still obtain valid measurements by
insulating tests within unused multicast addresses. However, in this
arrangement, rvperfm traffic can still affect the performance of other deployed
network applications.
rvd Reliability
To ensure accurate and efficient testing, it is critical that you first disable the
reliable message storage feature of rvd. To do so, manually start rvd (or rvrd)
with the command line parameter -reliability 0. This zero value instructs rvd
not to retain outbound messages in case they are needed for retransmission. For
more information, see Reliability and Message Retention Time on page 41.
rvperfm attempts to determine the carrying capacity of the network. To do so, it

tests whether the network and a set of receivers can absorb a run of messages
without missing any packets. The reliable delivery feature of rvd defeats this
purpose; it compensates for transient network problems by retaining and
retransmitting packets. This behavior is often beneficial in a production

Before You Test 203
|
environment, but in a performance testing situation it is counterproductive—by

compensating for network problems, it delays detection of those problems. This
delay falsifies the results of performance testing, and unnecessarily prolongs the
testing period.

204
rvperfm
Command
Syntax rvperfm [-service <service> ]

[-network <network> ]
[-daemon <daemon> ]
[-subject <subject> ]
[-inbox]
[-auto]
[-messages <m> ]
[-size <size> ]
[-interval <interval> ]
[-batch <batch_size> ]
[-cm]
[-cm-name <name> ]
[-cm-ledger <filename> ]
[-cm-sync]
[-h]
Purpose rvperfm coordinates the tasks of measuring network performance. It sends

messages to the network, and reports statistics to stdout.
Remarks In single mode (without the flag -auto), rvperfm sends one run of messages, and
then exits.
In automatic mode (with the flag -auto), rvperfm sends several runs of
messages, adjusting the batch size and interval parameters to empirically
determine the combination that yields maximum network throughput. After it
finds the optimal settings, it exits; the parameters and report of the final run
reflect optimal network performance. For details, see Automatic Mode—Binary
Search on page 199.
Outline Each run consists of these steps:

1. Dynamically discover the available rvperfs processes; output a list of
participating instances. In the discovery step, rvperfm polls for listeners, and
waits 3 seconds for ready signals from rvperfs processes; then it continues to
the next step.
2. Send the run of messages.
3. Output statistics that measure the performance of the sender.
4. Output statistics that measure the performance of each receiver (if any).
5. Output a summary of error advisories pertaining to the sender.
Collision When two instances of rvperfm (simultaneously) attempt to use the same subject,
service and network, at least one of them detects the collision and exits
immediately.

rvperfm 205
|
Simultaneous instances that differ in subject or service (or both) do not constitute
a collision. Such processes can coexist.
(Sheet 1 of 4)
-service <service> <service> is the service name or UDP or PGM port number that defines
the service group.
See Service Selection on page 20.
If you do not specify the -service parameter, the default value is 7599.
-network <network> <network> narrows the service group by selecting a local network by
network name or IP network number (when the host computer has
multiple network interfaces). It can also specify multicast addresses.
See Network Selection on page 23.
If you do not specify the -network parameter, the default value is the
multicast address ";225.9.9.9". On operating systems that do not
support multicast addressing, you must supply a valid broadcast
network address.
-daemon <daemon> The -daemon parameter instructs the program about how and where to
find rvd and establish communication.
See Daemon Client Socket—Establishing Connections on page 28.
Daemon on page 29. However, the program cannot start a remote
daemon automatically—you must start it manually on the remote
computer.
If you do not specify the -daemon parameter, the program finds the local
daemon on TCP socket 7500.

206
(Sheet 2 of 4)
-subject <subject> rvperfm sends messages to this subject name.
If you specify neither -subject nor -inbox, then the program uses
_perf as a prefix to construct broadcast subjects.
-inbox rvperfm sends point-to-point messages

rvperfm probes the network to discover available instances of rvperfs.
The first instance to respond becomes the sole receiver—rvperfm sends
point-to-point messages only to an inbox in that process instance.
(Since rvperfm uses broadcast subjects for the initial discovery phase, it
is not a contradiction to specify both -inbox and -subject parameters.
When both parameters are present, -inbox determines the sending
behavior.)
-auto When present, rvperfm operates in automatic mode, sending several runs
of messages to automatically determine the optimal batch size and
interval parameters for the network.
When absent, rvperfm operates in single mode, sending only one run of
messages.
See also, Automatic Mode—Binary Search on page 199.
-messages <m> rvperfm sends <m> messages per run.

If not present, the default is 10000 messages per run.
-size <size> rvperfm sends messages with <size> bytes of payload data.
Use this size to model application data rates. This size does not include
message header data nor packet overhead, so computing the network
byte transfer rate from this size results in an slight underestimate of the
actual throughput.
If not present, the default is 256 payload bytes in each message.

rvperfm 207
|
(Sheet 3 of 4)
-interval <pause> rvperfm sends messages in batches, waiting for <pause> seconds between
the end of one batch and the start of the next batch.
When absent, the default pause is zero seconds.
In single mode, rvperfm sends the run with this interval.
In automatic mode, rvperfm sends the first run with this interval,
adjusting the parameters in subsequent runs.
Change of Units: In earlier releases the value of this parameter was

interpreted as milliseconds—now it is a floating point value interpreted
as seconds.
-batch <batch_size> rvperfm sends messages in batches, with <batch_size> messages in each
batch.
The default is 10 messages per batch.
In single mode, rvperfm sends the run with this batch size.
In automatic mode, rvperfm sends the first run with this batch size,
adjusting the parameters in subsequent runs.
-cm When present, rvperfm sends messages with certified delivery features.
If rvperfs also specifies -cm, then the programs establish a certified
delivery agreement.
-cm-name <name> When present, rvperfm specifies this reusable correspondent name
when it enables certified delivery.
When -cm is present, but -cm-name is not, rvperfm operates with a
non-reusable correspondent name.
-cm-ledger <filename> When present, rvperfm uses this ledger file. You must also supply
-cm-name.
-cm-sync When present, then operations that update the ledger file do not return
until the changes are written to the storage medium. You must also
supply -cm-ledger and -cm-name.
When absent, the operating system writes ledger file changes to the
storage medium asynchronously.

208
(Sheet 4 of 4)
-h When present, output a parameter usage list to stdout, and exit
immediately.

rvperfs 209
|
rvperfs
Command
Syntax rvperfs [-service <service> ]

[-network <network> ]
[-daemon <daemon> ]
[-subject <subject> ]
[-cm]
[-cm-name <name> ]
[-cm-ledger <filename> ]
[-cm-sync]
[-h]
Purpose rvperfs listens for messages from rvperfm, gathers and reports statistics to
rvperfm at the end of each run.
Remarks rvperfs operates passively; it sends messages only in response to requests from
rvperfm.
You can leave process instances of rvperfs running idle. Each instance of
rvperfs can report statistics from several consecutive process instances of
rvperfm—as long as only one rvperfm executes at a time. You can relocate the
rvperfm process from one host computer to another without restarting the
rvperfs processes.
Unlike rvperfm, an rvperfs process never exits by itself. You must explicitly
terminate each rvperfs process.
In addition to sending its statistics to rvperfm, rvperfs also prints its report to
stdout.
(Sheet 1 of 3)
-service <service> <service> is the service name or UDP or PGM port number that defines
the service group.
See Service Selection on page 20.
If you do not specify the -service parameter, the default value is 7599.

210
(Sheet 2 of 3)
-network <network> <network> narrows the service group by selecting a local network by
network name or IP network number (when the host computer has
multiple network interfaces). It can also specify multicast addresses.
See Network Selection on page 23.
If you do not specify the -network parameter, the default value is the
multicast address ";225.9.9.9".
-daemon <daemon> The -daemon parameter instructs the program about how and where to
find rvd and establish communication.
See Daemon Client Socket—Establishing Connections on page 28.
Daemon on page 29. However, the program cannot start a remote
daemon automatically—you must start it manually on the remote
computer.
If you do not specify the -daemon parameter, the program finds the local
daemon on TCP socket 7500.
-subject <subject> rvperfs listens for messages with this subject name.
If this parameter is absent, then rvperfs uses _perf as a prefix to
construct broadcast subjects.
(When you specify the -inbox flag to rvperfm, you need not specify this
rvperfs parameter.)
-cm When present, rvperfs listens for messages using certified delivery
features. If rvperfm also specifies -cm, then the programs establish a
certified delivery agreement.
-cm-name <name> When present, rvperfs specifies this reusable correspondent name
when it enables certified delivery.
When -cm is present, but -cm-name is not, rvperfs operates with a
non-reusable correspondent name.
-cm-ledger <filename> When present, rvperfs uses this ledger file. You must also supply
-cm-name.

rvperfs 211
|
(Sheet 3 of 3)
-cm-sync When present, then operations that update the ledger file do not return
until the changes are written to the storage medium. You must also
supply -cm-ledger and -cm-name.
When absent, the operating system writes ledger file changes to the
storage medium asynchronously.
-h When present, output a parameter usage list to stdout, and exit

immediately.

212
Interpreting the Report
This section describes the output from rvperfm.

First, rvperfm outputs a header, version information, and a summary of its
configuration parameters.
Next it polls the network to discover existing rvperfs processes. Each rvperfs
process resets itself and signals its readiness to participate in a new run. When
rvperfm receives the ready signals, it prints an identifier for each participating
rvperfs.
rvperfm prints a brief string as it begins sending the run of messages, and another
when it finishes sending the run. Then it outputs its run report:
1. Statistics that rvperfm collects while sending the messages.
2. Statistics that each rvperfs process collects while receiving messages. Each
group of statistics represents the performance of one rvperfs process.
rvperfm Example Report

The annotated rvperfm transcript in Figure 48 on page 213 shows the result of a
run with one rvperfs process receiving the messages.

Interpreting the Report 213
|
Figure 48 Report from rvperfm
TIB/Rendezvous performance analysis program

Copyright 1997-2001 by TIBCO Software Inc.
All rights reserved.
Version 6.7.5
Configuration parameters
Service: 8000
Network: ;225.9.9.9
Daemon: 8888
Subject: _perf
Number of messages: 102400

Payload bytes per message: 1024
Total payload bytes: 104857600 (100.0Mb)
Batch interval: 0.000000

Batch size: 1
Run #1 beginning...
Batch interval: 0.000000 rvperfm probes for rvperfs

Batch size: 1 processes, and outputs an
identifier for each rvperfs
Resetting receivers
Reset acknowledgment received from _INBOX.0A650224.1E0743AA4617B2004CDE8.1
Send messages
Number of receivers 1 Time to send the messages
Sending data... Report of send statistics
Sending complete
Elapsed time: 9.724587 seconds
Number of messages: 102400
Size of payload: 1024
Total payload bytes: 104857600
Batch Interval: 0.000000
Batch size: 1
Messages/second: 10530.010
Payload Bytes/second: 10782730.413 (10.3Mb) Actual send rate
Receive statistics
from rvperfs
Report from receiver _INBOX.0A650224.1E0743AA4617B2004CDE8.1
Messages received: 102400 (100.0%) All messages
arrived
Actual receive rate
Payload Bytes/second: 10274841.143 (9.8Mb)
Run complete

214
rvperfs Example Report

The excerpt in Figure 49 illustrates the output of rvperfs. First, the rvperfs
process reports its configuration parameters. Next it outputs its globally unique
inbox name, by which you can identify it in rvperfm reports.
Then rvperfs reports a reset message from rvperfm, signaling the start of a run.
At the end of the run, rvperfs reports its statistics.
Figure 49 Report from rvperfs
TIB/Rendezvous performance analysis program

Copyright 1997-2001 by TIBCO Software Inc.
All rights reserved.
Version 6.7.5
Configuration paramters
Service: 7599
Network: ;225.9.9.10 This inbox name identifies this process
Daemon: NULL instance of rvperfs. The same name
Subject: _perf appears in rvperfm report to denote
this rvperfs process.
My name is _INBOX.0A65034A.DDF3B32312A8085470.1
Ready...
rvperfm prepares for a
Reset received from _INBOX.0A6503F6.10D3B324033911710.1
new run.
Test message received
This inbox name identifies
Run beginning...
that rvperfm process.
Run complete
Elapsed time: 6.035
receiver
Messages received: 20000
statistics
Certified Delivery Agreements

When the performance programs use certified message delivery, rvperfm prints
information about registration requests in its output; for example:
rvperfm Resetting receivers

Reset acknowledgment received from
_INBOX.0A65034A.DEA3B32324F8085470.2
CM registration request received from rvperfs
Number of receivers 1
Similarly, rvperfs prints information about certified delivery registration in its

output:

|
rvperfs Ready...
Reset received from _INBOX.0A6503F6.11D3B3241239116F0.2
CM registration received from rvperfm
Test message received
Run beginning...
Elapsed Time
Both programs in the performance tool report the total time that elapsed in each
complete run. The speed at which the Rendezvous daemon can deliver messages
to the network depends on the network itself, the network interface card (and
other hardware parameters), and the host operating system. If rvperfm sends at a
faster rate than the network can accept, rvperfm retains messages in its outbound
queue until the network can accept them.
Sending complete
In this example, 9.737 seconds elapsed from the time that rvperfm sent the first
message of the run, until the time that the daemon transmitted the last message of
the run to the network.

216
Usage and Examples
The Rendezvous performance assessment tool is extremely flexible; it can

measure performance in many different configurations of hardware, operating
systems, network topologies, and operating conditions. The results can guide
hardware purchases, tune for optimal network performance, or validate the
suitability of Rendezvous software in specific situations. The remaining sections
of this chapter present selected examples.
Remember, it is crucial to gauge performance in actual deployment networks,
rather than in a laboratory. Benchmarks produced in one network rarely apply to
other networks. Changing the network (by adding or removing computers,
routers, or other elements) can change performance dramatically.
Network Stress
On a fast computer Rendezvous software can overwhelm the capacity of the

network. Other programs operating during this kind of performance test can
display symptoms of network stress.

Hardware Capabilities 217
|
Hardware Capabilities
In this group of examples, the performance assessment tool measures the speed of
specific computers—individually or in a group.
Maximum Sustained Send Rate

What is the maximum sustained rate at which a specific computer can send a
stream of messages?
To answer this question, run rvperfm in automatic mode on the sending
computer, without any rvperfs processes to receive the messages; select a
message size that reflects the messages that your application will send when
deployed.
sender> rvperfm -auto -size 1000
After rvperfm experiments with its parameters, the final run indicates the values
that yield the maximum send rate for the sending computer under prevailing
network conditions.
Optimal Sustained Receive Rate

What is the maximum rate at which a specific computer can receive a stream of
messages?
To answer this question, run rvperfs on the receiving computer. Then run
rvperfm in automatic mode on another computer; select a message size that
reflects the messages that your application will send when deployed.
receiver> rvperfs
sender> rvperfm -auto -size 1000
After rvperfm experiments with its parameters, the final run indicates the values
that yield the optimal receive rate for the receiving computer under prevailing
network conditions.
To validate this receive rate, check that it is strictly less than the maximum send
rate of the sender. If rvperfm on the sending computer has successfully sent a run
of messages at a rate greater than the optimal receive rate, then the receive rate is
valid. If not, the sender might be limiting the receive rate. To test the sender, see
Maximum Sustained Send Rate on page 217.
A similar test with several receivers determines the optimal rate of the slowest
receiver.

218
Fixed Receive Rate

Can all computers on this network receive 2000-byte messages at a sustained rate
of approximately 5 batches per second, with 10 messages per batch?
To answer this question, run rvperfs on each of the receiving computers. Then
run rvperfm in single mode on another computer.
receiver1> rvperfs
receiver2> rvperfs
...
receiver42> rvperfs
sender> rvperfm -size 2000 -batch 10 -interval .2
The run report indicates whether the receivers keep pace with the sender under
prevailing network conditions.

Wide Area Networks 219
|
Wide Area Networks
In a wide area network (WAN) the transit time between sites can limit
throughput. To keep information flowing smoothly, it is essential to measure the
optimal throughput rates for the entire WAN, and limit sending rates to avoid
exceeding overall network capacity.
Consider a global network connected using the Rendezvous routing daemon,
rvrd. You can use the performance assessment tool for these tasks:
• Measure optimal sustainable throughput rates for the entire WAN.

• Compare actual speed and throughput of available WAN carrier links.
• Compare different neighbor configurations between rvrd components.
• Select rvrd host hardware.
• Demonstrate the effects of exceeding network capacity.
• Discover optimal locations from which to send messages to the rest of the
network.

220
Certified Message Delivery
Certified message delivery introduces additional complexity. The performance

assessment tool can help you measure its effects on application performance.
When the -cm parameter is present, rvperfm sends messages using Rendezvous
certified delivery features. Before each run, it clears its ledger (whether file-based
or process-based), and sends a test message to provoke -cm receivers to register
for certified delivery. After the registration period, it sends the run of messages.
Number of Certified Receivers

When a certified sender process is operating near maximum capacity (either the
capacity of its host computer, or the network capacity), then the number of
certified receivers can dramatically affect the timing results.
Throughput of certified messages decreases as the number of registered receivers
increases. This decrease is a direct result of confirmation messages flowing back
from certified receivers to the sender. You can use the performance tool to
measure the network capacity for certified messages with varying numbers of
registered receivers.
Ledger
Certified delivery depends on a ledger to track messages and confirmations. Two
types of ledger are available; each has a different effect on performance:
• A file-based ledger with asynchronous I/O offers persistence at the cost of
disk operations. With asynchronous file I/O, some information could be lost
in the event of sudden termination.
• A file-based ledger with synchronous I/O offers greater certainty at the cost of
additional speed because the disk write operations block. Synchronous file
I/O dramatically reduces the probability of lost information in the event of
sudden termination.
You can use the performance tool to compare the effect of these three options on
certified message throughput.

Very Large Messages 221
|
Very Large Messages
Rendezvous software can transport very large messages; it divides them into
small packets, and places them on the network as quickly as the network can
accept them. In some situations, this behavior can overwhelm network capacity;
applications can achieve higher throughput by dividing large messages into
smaller chunks and regulating the rate at which it sends those chunks. You can
use the performance tool to evaluate chunk sizes and send rates for optimal
throughput.
This example, sends one message consisting of ten million bytes. Rendezvous
software automatically divides the message into packets and sends them.
However, this burst of packets might exceed network capacity, resulting in poor
throughput:
sender> rvperfm -size 10000000 -messages 1
In this second example, the application divides the ten million bytes into one
thousand smaller messages of ten thousand bytes each, and automatically
determines the batch size and interval to regulate the flow for optimal
throughput:
sender> rvperfm -size 10000 -messages 1000 -auto
By varying the -messages and -size parameters, you can determine the optimal
message size for your applications in a specific network. Application developers
can use this information to regulate sending rates for improved performance.

222
Sufficiency and Effects
Designers of distributed applications need to assess the effect of a proposed

application on the network—long before deployment, and often before any code
exists. The performance assessment tool can help answer questions such as these:
• Can Rendezvous software in this network transfer data at the rate projected for
this application?
• Increased message traffic affects the operation of network infrastructure and
elements such as routers, WAN links, individual computers, and previously
deployed network applications (including Rendezvous applications, as well
as mounted remote file systems, telnet, and others). What are the secondary
effects of deploying an application that sends messages at the projected data
rate?
Limits of Performance Assessment
Although the performance assessment tool can measure sufficiency of network

transport, and the secondary effects of projected message traffic, its
measurements are an idealized abstract. It cannot measure the total effect of a
proposed, and as yet unimplemented, application.
Generating data to send in messages, processing inbound messages, displaying
data from inbound messages to the user—all of these activities and their affect on
the application’s host computer are beyond the scope of the performance
assessment tool. For example, this tool can determine that the network can absorb
300 query messages per second, but this figure does not indicate whether a
database application can actually process queries and return results at that rate.
The performance assessment tool can establish an upper bound on application
message transport performance, and help gauge some of the secondary effects,
but it cannot prove an application as a whole will operate properly.

Locating Performance Obstacles 223
|
Locating Performance Obstacles
An application that performs more poorly than expected could be sending

messages faster than the network can accept them. The performance assessment
tool can help in two ways:
• Use rvperfm in automatic mode to determine the optimal send rate for the
network. Then adjust the application to send messages at that rate.
For a specific example of this method, see Very Large Messages on page 221.
• Set rvperfm parameters to mimic the sending behavior of the application.
Then adjust rvperfm parameters to improve performance. Finally, adjust the
application’s behavior.
A network protocol monitor (such as rvtrace) can help you diagnose
performance obstacles using this method. For more information, see Protocol
Monitor (rvtrace) on page 225.

224

| 225
Chapter 11 Protocol Monitor (rvtrace)
This chapter describes rvtrace, the Rendezvous protocol monitoring tool, which
is distributed with Rendezvous Software Release 7.2.
Topics
• Overview, page 226

• Limitations, page 227
• Passive Monitor, page 229
• The pcap Facility, page 230
• Data Capture Files, page 231
• rvtrace, page 232
• Filtering, page 239
• Interpreting the Report, page 241
• Multicast Data Statistics, page 244
• Multicast Retransmit Statistics, page 248
• Point-to-Point Statistics, page 255
• Subject Statistics, page 259
• SNMP, page 262

226
| Protocol Monitor (rvtrace)
Overview
Rendezvous protocol monitor, rvtrace, is a tool for network administrators. It

monitors network packets, categorizes them, and reports statistics at regular
intervals.
Network administrators can use rvtrace to diagnose network difficulties in real
time, answering questions such as these:
• Which computers are inundating the network?
• Which computers are sending or receiving an inordinate number of
retransmission requests?
Snapshots
rvtrace operates by capturing network packets, extracting information from
packet headers, and gathering statistics about those packets. At the end of each
interval, it compiles a statistical snapshot, and resets its counters for the next
interval.
rvtrace can output those statistics in table format, or you can use SNMP to query
the most recent snapshot.
Prerequisites
rvtrace is a tool for experienced network administrators.
• You must already understand IP protocols and addressing conventions.
• You must already understand Rendezvous software from an administrator’s
perspective.
• To use rvtrace effectively, you must understand the topology of your
network.
Licensing
rvtrace is sold and licensed separately from other Rendezvous components.
After purchasing rvtrace, you must include the rvtrace license ticket in the file
tibrv.tkt. If rvtrace does not find a valid license ticket, it runs for a 10-minute
evaluation period.

Limitations 227
|
Limitations
Range Limitations
rvtrace cannot examine packets unless they traverse the immediate network
segment in which rvtrace is running. For example, point-to-point conversations
within or between other network segments are invisible to rvtrace. Most
saliently, retransmission requests and retransmission rejections are point-to-point
packets, so they are visible to rvtrace only when they either originate or
terminate in the local network segment. Consequently, in some situations
rvtrace can detect retransmission broadcasts, even though it cannot detect the
point-to-point packets that request retransmissions.
Switched network environments (such as switched Ethernet, or ATM) further
limit the usefulness of rvtrace as a diagnostic tool. Since switching hardware
forwards every point-to-point packet directly to its destination host, rvtrace
detects point-to-point packets only when they either originate or terminate in the
computer running rvtrace. In some switched networks, you can ameliorate this
situation by disabling switching behavior—for example, by setting one port to
diagnostic mode, or by using a diagnostic utility. This tactic can yield the full
stream of point-to-point packets in a limited portion of the network; run rvtrace
in that portion.
In addition, some network switching hardware can route multicast packets to a
network segment only when a host in the segment is actually listening to the
corresponding multicast group. Such high specificity further limits the range of
rvtrace.
Protocol Limitation
rvtrace supports only UDP multicast and UDP point-to-point protocols. It does
not support PGM or RPTP protocols.
Interface Limitation
rvtrace supports only Ethernet interfaces.
rvtrace does not support these (or any other) non-Ethernet interfaces: Token
Ring, FDDI, ATM.

228
Platform Support and Limitations

rvtrace operates on all platforms that Rendezvous supports—except VMS and
OS/390 (MVS).
TIBCO supports rvtrace on Microsoft Windows platforms, but requires that you
first obtain and install WinPcap (see Obtaining pcap on page 230).
However, we do not support rvtrace on Windows SMP (Symmetric

Multi-Processor) platforms at this time.
WinPcap does not support SMP platforms, and might not operate correctly in
multiprocessor environments. For more information, see
winpcap.polito.it/misc/faq.htm.
On Windows platforms, we strongly recommend that you upgrade to the most
recent version of WinPcap.
UnixWare places security restrictions on programs that open interfaces in

promiscuous mode (such as pcap). To run rvtrace on UnixWare platforms, you
must dedicate a separate physical interface for that purpose.

Passive Monitor 229
|
Passive Monitor
rvtraceis a passive monitor. It neither uses nor interferes with Rendezvous

daemon processes. rvtrace does not add any packet traffic to the network.
rvtrace does not require a Rendezvous daemon for its operation. Instead, it
collects network packets using the pcap facility.
Performance Effects
Although rvtrace is a passive monitor, it opens the network device in

promiscuous mode, which consumes CPU and network resources on its host
computer (in proportion to total network traffic). Running rvtrace on the same
computer as any Rendezvous daemon (rvd or routing daemon) indirectly affects
the operation of the local daemon by consuming these resources. Running rvd
and rvtrace together on the same computer changes the timing and loading
profiles of the host computer.
Avoid this situation whenever possible. Instead, run rvtrace on a computer that
is otherwise free of Rendezvous activity.
We further recommend that rvtrace run on a computer that is fast enough to
process every Ethernet packet that appears at its network interface.

230
The pcap Facility
rvtrace uses the pcap facility to capture network packets.
Obtaining pcap
Before using rvtrace, you must first ensure that the pcap facility is properly
installed.
On most UNIX platforms, pcap is ready to use.
For Windows (NT, 2000 and XP), you can download the WinPcap NDIS packet
capture driver from this URL:
• netgroup-serv.polito.it/winpcap/
If this URL is no longer current, consult the Rendezvous Release Notes

(relnotes) for an updated URL.
Packet Filtering
pcap has a flexible filtering language for selecting the set of packets to capture.
rvtrace inherits this language through its -filter parameter.
You can select packets based on source, destination, host, network interface, port,
packet length, and protocol. Packets that match the filter appear in rvtrace
output; packets that do not match are ignored.
See Also
-filter <expr> on page 235
Filtering, page 239

Data Capture Files 231
|
Data Capture Files
rvtrace can write packets into a capture file, and read a stream of packets from a
file (as if from the network).
Motivation
Packet capture files are an important tool for problem diagnosis. Several
techniques are useful:
• Capture packet data for later analysis.
• Capture packet data for further analysis at a remote location.
• Capture packets at high speed, then replay later when I/O delays are
acceptable.
In general, rvtrace can capture packets to a file faster than it can display
statistics. Large amounts of display data can create I/O delays, which could
cause rvtrace to miss packets. For example, in a heavily loaded network,
displaying subject statistics for many subjects could have this undesirable
result.
You can use data capture files to side-step this difficulty. For example, capture
a five-minute snapshot of packets (capturing suppresses display); then replay
packets from the file, displaying statistics when the consequences of I/O
delays are no longer problematic.
Output File Rotation

The rotation regimen for data capture output is almost identical to the rotation
regiment for daemon log files; see Log Rotation on page 43.
The only difference between them, is that rvtrace always deletes an older existing
file before opening a file for writing packet data. (That is, it never appends to the
end of an existing file.)

232
rvtrace
Command
Syntax rvtrace [-i <interface> ]

[-r <input_file> ]
[-addr <expr> ]
[-src <expr> ]
[-dst <expr> ]
[-port <expr> ]
[-filter <expr> ]
[-w <output_file> ]
[-w-rotate <size> ]
[-no-display]
[-addrinfo]
[-u <update_interval> ]
[-no-mcast]
[-ptp]
[-no-subjects]
[-hostmsgs]
[-rate]
[-logfile <log_file> ]
[-log-rotate <size> ]
[-snmp]
[-foreground]
[-h]
Purpose rvtrace is a network protocol monitor that specializes in Rendezvous protocols.

It collects and prints statistics about network packets.
Remarks rvtrace runs in a loop—capturing packets, analyzing them, categorizing them,

and periodically printing a summary to standard output.
An rvtrace process never exits by itself (except as a consequence of a command
syntax error); you must explicitly terminate each process.
Delimit all parameters and arguments with a space character.
(Sheet 1 of 5)
Data Source
-i <interface> The program monitors packets on the network interface with this name. If
absent, the default value varies, depending on operating system and
network hardware.

rvtrace 233
|
(Sheet 2 of 5)
-r <input_file> When present, read recorded packets from <input_file> instead of a network
interface.
This option overrides the -i parameter.
For more information, see Data Capture Files on page 231.
Data Filtering
-addr <expr> Filter the set of packets to process only those with source or destination in
the set of hosts or networks specified in <expr>. For filter expression syntax
and semantics, see Filtering on page 239.
Enclose filter expressions in quotation marks (").
The parameter -addr <filter> is equivalent to:
-filter udp and (src <filter> or dst <filter>)
When any of the parameters -src, -dst, -addr, or -port are present,
rvtrace concatenates them into a single effective filter. However, when
the -filter parameter is present, rvtrace ignores all four of these
parameters, and -filter overrides them.
-src <expr> Filter the set of packets to process only those that originate from the set of
hosts or networks specified in <expr>. For filter expression syntax and
semantics, see Filtering on page 239.
The parameter -src <expr> is equivalent to:
-filter udp and src <expr>

234
(Sheet 2 of 5)
-r <input_file> When present, read recorded packets from <input_file> instead of a network
interface.
This option overrides the -i parameter.
Data Filtering
-addr <expr> Filter the set of packets to process only those with source or destination in
the set of hosts or networks specified in <expr>. For filter expression syntax
and semantics, see Filtering on page 239.
The parameter -addr <filter> is equivalent to:
-filter udp and (src <filter> or dst <filter>)
-src <expr> Filter the set of packets to process only those that originate from the set of
The parameter -src <expr> is equivalent to:
-filter udp and src <expr>

rvtrace 235
|
(Sheet 3 of 5)
-dst <expr> Filter the set of packets to process only those with destination in the set of
The parameter -dst <filter> is equivalent to:
-filter udp and dst <filter>
-port <expr> Filter the set of packets to process only those with destination port in the
set of ports specified in <expr>. For filter expression syntax and semantics,
see Filtering on page 239.
The parameter -port <port> is equivalent to:
-filter udp and dst port <port>
-filter <expr> Filter the set of packets to process only those that match <expr>. For filter
expression syntax and semantics, see Filtering on page 239.
When present, this parameter overrides the -src, -dst, -addr, and -port
parameters.

236
(Sheet 4 of 5)
Data Capture
-w <output_file> When present, write packet information to <output_file> for later replay or
analysis.
When absent, do not record packet information to a file.
When -w is present, rvtrace does not display statistics. To see statistics,
use -r to read the packet capture file.
When both -r and -w are present, rvtrace reads packets from <input_file>,
filters them, and then recaptures the filtered packets to <output_file>. You
can use this technique to prune an existing capture file by reducing
information or filtering extraneous traffic.
-w-rotate <size> When present, activate the rotation regimen for the data capture
<output_file>, limiting the combined total size of the 10 log files to this size
(in megabytes). For details, see Output File Rotation on page 231.
When you specify this option, you must also specify -w.
When absent, do not rotate the data capture file.
Statistics
-no-display When present, do not output statistics. Nonetheless, rvtrace continues to

compile statistics, which are available through SNMP queries.
When absent, rvtrace outputs statistics (either to stdout, or to a log file).
-u <update_interval> Summarize network packet at this time interval (in seconds). If absent, the
default value is 10 seconds.
-addrinfo When present, display network totals, subtotals, and detail rows.
When absent, display only network totals and subtotal rows.
For example output, see Figure 50, rvtrace Output with -addrinfo, on
page 242, and Figure 51, rvtrace Output without -addrinfo, on page 243.
-no-mcast When present, omit the multicast table.

When absent, display the multicast table; see Multicast Data Statistics on
page 244.

rvtrace 237
|
(Sheet 5 of 5)
-ptp When present, display the point-to-point table; see Point-to-Point Statistics
on page 255; see also Range Limitations on page 227.
When absent, omit the point-to-point table.
-no-subjects When present, omit the subject table.

When absent, display the subject table; see Subject Statistics on page 259.
-hostmsgs When present, display Rendezvous HOST messages at the conclusion of

each interval. TIBCO personnel might request that you supply rvtrace
output transcript that includes these messages. These messages useful only
to TIBCO personnel.
-rate When present, display packet counts as per-second rates.

When absent, display the actual number of packets in the update interval.
Log Output
-logfile <log_file> Send log output to this file.

When absent, the default is stdout.
-log-rotate <size> When present, activate the log rotation regimen, limiting the combined
total size of the 10 log files to this size (in kilobytes). For details, see Log
Rotation on page 43.
When you specify this option, you must also specify -logfile.
Other
-snmp When present, rvtrace starts its internal SNMP agent.

When absent, rvtrace does not start its SNMP agent.

When present, rvtrace runs as a foreground process.
When absent, rvtrace runs as a background process.
-h When present, output a parameter usage list to standard output, and exit
immediately.

238
Errors • rvtrace uses the pcap facility, which requires root privileges (because it must
open the raw ethernet device in promiscuous mode). Without appropriate
privileges, pcap denies permission to initialize, and rvtrace exits
immediately.
• The pcap library calls reject improperly formed filter expressions. It reports
them with messages such as this:
pcap_compile: syntax error
This error causes rvtrace to exit.

Filtering 239
|
Filtering
You can narrow the set of packets that rvtrace processes by supplying either the
-filter parameter, or a combination of the -src, -dst, -addr, and -port
parameters. Filter expressions specify the set of packets to process.
rvtrace uses the pcap facility to capture and filter packets. The tcpdump utility
also uses pcap, so the syntax and semantics for rvtrace and tcpdump filter
expressions are identical. Table 8 summarizes the subset of filter expressions that
are relevant to rvtrace; for additional options, see documentation for tcpdump.
(Disclaimer: pcap and tcpdump are not TIBCO products; we do not sell, support
or document them.)
Each row of Table 8 constitutes an <expr>, and can be used in place of the syntax
marker <expr> elsewhere in Table 8, and in the parameter table for rvtrace.
When specifying a filter expression to an rvtrace parameter, enclose the
expression in quotation marks (").
Table 8 Filter Expressions (Sheet 1 of 2)
Element Description
Host Expressions
host <host> Process a packet if either the IP source or destination of the packet is
<host>. Specify <host> as a name or an IP address.
dst host <host> Process a packet if its IP destination is <host>.
src host <host> Process a packet if its IP source is <host>.
Network Expressions
net <net> Process a packet if either the IP source or destination of the packet is
<net>. Specify <net> as a name or an IP network number.
dst net <net> Process a packet if its IP destination is <net>.
src net <net> Process a packet if its IP source is <net>.

240
Table 8 Filter Expressions (Sheet 2 of 2)
Element Description
Port or Service Expressions
port <port> Process a packet if either the IP source or destination port of the packet is
<port>. Specify <port> as a service name or a UDP port number.
dst port <port> Process a packet if its IP destination port is <port>.
src port <port> Process a packet if its IP source port is <port>.
Broadcast or Multicast Expressions
ip broadcast Process a packet if it is an IP broadcast packet.

ip broadcast <expr> If <expr> is present, then process the packet only if it also meets the
criteria of <expr>.
ip multicast Process a packet if it is an IP multicast packet.

ip multicast <expr> If <expr> is present, then process the packet only if it also meets the
criteria of <expr>.
Protocol Expressions
udp Process a packet if it is an IP packet with protocol type udp. (All

udp <expr> Rendezvous packets are UDP packets.)
If <expr> is present, then process the packet only if it also meets the
criteria of <expr>.
ip Process a packet if it is an IP packet.

ip <expr> If <expr> is present, then process the packet only if it also meets the
criteria of <expr>.
Boolean Operators
Use parentheses to group boolean expressions; use appropriate escape characters to override
shell-specific semantics of parentheses.
<expr1> and <expr2> Process a packet if it meets both criteria.

<expr1> <expr2>
<expr1> or <expr2> Process a packet if it meets either criterion.
not <expr> Process a packet if it does not meet the criterion.

|
Interpreting the Report
The remaining sections of this chapter describe the output from rvtrace.
Figure 50 on page 242 shows a sample of the output that rvtrace prints at the
conclusion of each interval, when the -addrinfo flag is present:
• Time stamp—identifies the interval
• Multicast Data Statistics—summarizes Rendezvous multicast and broadcast
packets during the interval, organized by UDP port (service) and destination
address (see Multicast Data Statistics on page 244)
• Multicast Retrans Statistics—summarizes requests to retransmit packets of
multicast and broadcast data (this table does not appear in Figure 50; see
Multicast Retransmit Statistics on page 248)
• PTP Statistics—summarizes Rendezvous point-to-point packets during the
interval, organized by UDP port (service) and destination address (see
Point-to-Point Statistics on page 255)
• Subject Statistics—recapitulates Rendezvous multicast and broadcast message
activity during the interval, featuring information about subject names (see
Subject Statistics on page 259)
Notice that each table begins with a network total, and then breaks down the total
into subtotals and fine-grained categories.
Figure 51 on page 243 shows a sample of the less verbose output that rvtrace
prints when the -addrinfo flag is absent. Notice that tables omit the fine-grained
categories—displaying only the network total and subtotals
General Network Load

To assess network load, inspect the Data and Bytes columns of the Multicast Data
Statistics table, and the Data and Bytes columns of the Point-to-Point Statistics
table.
Number of Senders
To determine the number of Rendezvous daemons that sent data messages during
an interval, count the number of distinct source addresses in all source rows of the
Multicast Data Statistics table and the Point-to-Point Statistics table.

242
Scanning for Problems

To quickly review rvtrace output for problems, scan down the right side of the
page, looking for non-zero values in the Bad, Gaps, and Rbytes columns of the
multicast data tables. Non-zero values in these columns indicate a problem; look
more closely at statistics in other columns in that interval and subsequent
intervals.
Figure 50 rvtrace Output with -addrinfo
Snapshot 2001-06-11 11:14:24 (10.0 elapsed seconds)
Multicast Data Statistics

Port Address Data Bytes Null Rdata Rbytes Gaps Bad
----- --------------- ------- --------- ----- ------- --------- ------ -----
Totals 22 11796 14 0 0 0 0
5039 * 224.2.2.3 10 5200 5 0 0 0 0
10.101.2.57 10 5200 4 0 0 0 0
10.101.3.67 0 0 1 0 0 0 0
5662 * 224.2.2.3 11 6219 5 0 0 0 0
10.101.3.67 11 6219 5 0 0 0 0
7500 * 10.101.2.255 1 377 1 0 0 0 0
10.101.2.66 1 377 1 0 0 0 0
8900 * 10.101.2.255 0 0 3 0 0 0 0
10.101.2.35 0 0 3 0 0 0 0
Subject Statistics
Port Address Msgs Bytes Subject
----- --------------- ------- --------- -------
Totals 22 11796
5039 * 224.2.2.3 10 5200 subject.1
10.101.2.57 10 5200
5662 * 224.2.2.3 1 359 _RV.INFO.SYSTEM.HOST.STATUS.0A650343
10.101.3.67 1 359
5662 * 224.2.2.3 10 5860 subject.1
10.101.3.67 10 5860
10.101.2.66 1 377

|
Figure 51 rvtrace Output without -addrinfo

----- --------------- ------- --------- ----- ------- --------- ------ -----
Totals 12 4334 25 2 508 0 0
5039 * 224.2.2.3 2 571 5 0 0 0 0
5492 * 224.1.2.2 7 2962 9 0 0 0 0
5662 * 224.2.2.3 1 170 2 0 0 0 0
7500 * 10.101.2.255 1 254 6 2 508 0 0
7535 * 10.101.2.255 1 377 2 0 0 0 0
7611 * 10.101.2.255 0 0 1 0 0 0 0
Subject Statistics
----- --------------- ------- --------- -------
Totals 12 4334
5039 * 224.2.2.3 1 170 P1
5039 * 224.2.2.3 1 401 S5
5492 * 224.1.2.2 7 2962 R31
5662 * 224.2.2.3 1 170 TTT.12
7500 * 10.101.2.255 1 254 FOO
Bad Packets
Bad packets lack UDP checksums, or are corrupt in some other way.
Bad packets usually indicate a severe misconfiguration or network problem.

Remedy the situation immediately.
Checksums are crucial to correct operation of Rendezvous software; see Enable

Packet Checksums on page 6.
False Bad In some situations, rvtrace can incorrectly report bad packets.
Packets
When a sending host computer enables checksum off-loading features, the
network interface card (rather than the CPU) adds checksums to outbound
packets. If rvtrace is running on the same host as the sender, it captures
outbound packets before the checksums have been added. rvtrace detects the
missing checksums, and reports bad packets. However, by the time these packets
actually reach the network, they might not be bad packets.

244
Figure 52 shows a multicast data table (from rvtrace -addrinfo). The text
below introduces important concepts. Table 9 on page 245 describes the columns
in detail.
Figure 52 Multicast and Broadcast Data Statistics

----- --------------- ------- --------- ----- ------- --------- ------ -----
Totals 25 6462 23 3 1042 4 0
5039 * 224.2.2.3 1 359 3 0 0 0 0
10.101.3.67 1 359 3 0 0 0 0
5090 * 224.1.2.5 10 2716 13 0 0 0 0
10.101.2.57 2 728 4 0 0 0 0
10.101.3.72 8 1988 9 0 0 0 0
5662 * 224.2.2.3 0 0 3 0 0 0 0
10.101.3.67 0 0 3 0 0 0 0
7500 * 10.101.2.255 14 3387 4 3 1042 4 0
10.101.2.57 4 1258 1 1 336 1 0
10.101.2.64 0 0 1 0 0 0 0
10.101.2.66 10 2129 2 2 706 3 0
Notice that the rows divide visually into four groups, as indicated by a number in
the Port column and an asterisk (*).
Network Total The first row (immediately after the table and column headings, and before the
Row four groups) is a network total row; the word Totals in the Address column is a
visual cue. This row shows the grand total of multicast and broadcast packets on
the network during the interval. For example, the Data column shows the total
number of data packets that rvtrace detected on the network during the interval.
The remaining rows display more fine-grained information about those packets—
grouping them by UDP service, destination address, and source address.
Subtotal Groups A number in the Port column indicates the UDP service for its row, and the group
of rows that follow it. A blank in this column means that the row has the same
port as the row above, and is part of the same subtotal group. Notice how the
pattern of numbers and blanks in the Port column visually indicates the subtotal
groups.
Destination Row * flags a row as a destination subtotal row. A blank (space character) in this column
flags a row as a source row. Each group begins with a destination subtotal row,
followed by one or more source rows.

Multicast Data Statistics 245
|
Each destination subtotal row is the heading and subtotal for the source rows that
follow it. For example, consider the destination row with 5090 in the Port
column, and 224.1.2.5 in the Address column. The Data column indicates 10
packets on UDP service 5090 sent to the multicast group 224.1.2.5. The two
subsequent source rows indicate that those 10 packets came from two sources—
10.101.2.57 sent 2 packets, while 10.101.2.72 sent 8 packets. The subtotal 10 in
turn contributes to the grand total 25 in the first row.
A destination subtotal row governs the source rows below it (until the next
destination subtotal row). That is, the UDP service (port) and address in the
governing row apply to those source rows. Similarly, the governing row address
implies either multicast or broadcast protocol, and this protocol also applies to the
statistics in the source rows that it governs. (Naturally, all of this information also
applies to the governing row itself.)
Source Row Each source row shows a very narrow subset of packet activity during the
interval—packets on a specific UDP service (port), with a specific destination
address, and originating at a specific source (IP address). The Address column
shows the source; the UDP service and destination address are specified in the
governing row (that is, the nearest preceding destination subtotal row).
Statistics In destination rows numbers in statistics columns count packets with the
destination specified in the Address column.
In source rows numbers in statistics columns count packets originating from the IP
address in the Address column.
In network total rows, numbers in statistics columns represent the packet totals for
the network during the interval.
Table 9 Multicast Data Statistics—Column Headings (Sheet 1 of 3)
Column Description
Port In destination subtotal rows, this column contains a UDP port number indicating the
Rendezvous service for the group of rows that it begins.
In source rows this column is blank; the service in the nearest preceding destination row
also applies to the source row.
* Asterisk (*) in this unlabeled column indicates a destination subtotal row.

Blank in this column indicates a source row.

246
Column Description
Address In destination rows this column shows the destination address shared among a group of
packets. It can be an IP address or a multicast group.
In source rows this column shows the IP address from which group of packets originate.
In network total rows, this column contains the word Totals.
Data Data packets.

This column shows the number of multicast or broadcast data packets.
Bytes Data bytes.

This column sums the number of payload bytes over the data packets (as counted in the
Data column).
Null Null packets.

When a Rendezvous daemon has no data packets to transmit, it periodically sends null
packets to maintain continuity. This column displays the number of null packets that
rvtrace detected.
Rdata Retransmitted data packets.

rvtrace counts retransmitted packets separately from first-time data packets. This
column displays the number retransmitted data packets during the interval. Semantics
of this column are otherwise analogous to the Data column.
For statistics concerning retransmission requests and rejections, see Multicast
Retransmit Statistics on page 248.
Rbytes Retransmitted bytes.

This column sums the number of payload bytes over the retransmitted data packets (as
counted in the Rdata column).
Gaps Sequence gaps.

rvtrace tracks the serial numbers of Rendezvous packets. The Gaps column counts the
missing packets in each sequence of multicast or broadcast data packets.
For more information, see Gaps Diagnoses on page 247.

Multicast Data Statistics 247
|
Column Description
Bad Bad packets.
This column shows the number of packets that lack UDP checksums, or are corrupt in
some other way.
See Bad Packets on page 243.
Gaps Diagnoses
A sequence gap can occur in two situations:
• rvtrace misses one or more packets; that is, the hardware or operating
system on which rvtrace is running drops one or more packets.
• The network infrastructure drops one or more packets between their source
and rvtrace.
To determine which of these two situations has actually occurred, check the Rdata
values within the interval and in subsequent intervals. If Rdata remains at zero,
then it is likely that rvtrace alone is missing packets. If Rdata is non-zero, then it
is likely that the network infrastructure is dropping packets (Rdata is non-zero
because other daemons on the network are requesting retransmission of the
missing packets).

248
Multicast Retransmit Statistics
Sending Rendezvous daemon process instances retransmit missed packets upon

request from receiving Rendezvous daemons. This table displays statistics related
to those retransmission requests. For statistics concerning the actual retransmitted
packets, see Multicast Data Statistics on page 244—in particular, the Rdata and
Rbytes columns.
The packets counted in this table are always point-to-point packets. In contrast, the
actual retransmitted data packets use the same protocol (multicast or broadcast)
as the original data packets that they recapitulate.
In switched ethernet environments point-to-point packets remain invisible to

rvtrace—except for packets addressed specifically to the rvtrace host
computer. This fact severely limits the usefulness of retransmit statistics in
switched networks.
In some switched networks, you can disable switching behavior—for example, by
setting one port to diagnostic mode, or by using a diagnostic utility. This tactic can
yield the full stream of point-to-point packets in a limited portion of the network;
run rvtrace in that portion.
Figure 53 shows a multicast retransmit table (from rvtrace -addrinfo). The text
below introduces important concepts. Table 10 on page 249 describes the columns
in detail.
Figure 53 Multicast Retransmit Statistics
Multicast Retrans Statistics

Port Address Rreq Rseq Rrej Bad
----- --------------- ------- --------- ----- ------
Totals 3 4 0 0
7500 3 4 0 0
* 10.101.2.57 1 1 0 0
2 3 0 0
* 10.101.2.64 0 0 0 0
1 1 0 0
* 10.101.2.66 2 3 0 0
0 0 0 0
Network Total The first row (immediately after the table and column headings) is a network total
Row row; the word Totals in the Address column is a visual cue. This row shows the
grand total of packets related to retransmission detected on the network during
the interval.

Multicast Retransmit Statistics 249
|
grouping them by UDP service, and destination or source IP address.
Port Subtotal Row The second row in Figure 53 is a port subtotal row—its columns subtotal the
statistics over the subsequent destination and source rows which it governs (until
the next port subtotal row).
A number in the Port column indicates the UDP service for its row, and the group
groups.
Destination and For each IP address with retransmission request activity, this table contains a
Source Rows destination row and a source row—always paired in that order. An * and an IP
address (in the Address column) flags a row as a destination row. A blank (space
characters) flags a row as a source row. The address in the destination row also
applies to the source row that immediately follows it.
Counting Packets This table displays each packet twice—once in a destination row, and once in a
source row.
In each statistical column, the number in the port subtotal row is equal to the sum
of the values in the destination rows, which is also equal to the sum of the values
in the source rows.
In many networks it is possible to match the numbers in the source row for one IP
address against the numbers in the destination row for another IP address. From
this information you can deduce which Rendezvous daemons are missing packets
and requesting retransmissions.
Table 10 Multicast Retransmit Statistics—Column Headings (Sheet 1 of 2)
Column Description
Port In port subtotal rows, this column contains a UDP port number indicating the
In destination and source rows this column is blank; the service in the nearest
preceding port subtotal row governs the destination and source rows below it.
* Asterisk (*) in this unlabeled column indicates a destination row.


250
Table 10 Multicast Retransmit Statistics—Column Headings (Sheet 2 of 2)
Column Description
Address In destination rows this column shows the destination IP address of retransmission
request packets (that is, the Rendezvous daemon that originally sent data packets).
In source rows this column shows the IP address from which retransmission request or
rejection packets originate (that is, the Rendezvous daemon that missed receiving data
packets).
Rreq Retransmission requests.

This column displays the number of packets that contain retransmission requests.
Each request packet counts separately, even if several request packets specify the same
data packet numbers for retransmission. For example, if two daemons each request
retransmission of the data packets numbered 121–125, and a third daemon requests
retransmission of the data packets numbered 100–144, then Rreq is 3.
Rseq Retransmission sequence numbers.

Each retransmission request packet can solicit one or more data packets for
retransmission. This column sums the number of data packets for which retransmission
is requested over the request packets (as counted in the Rreq column).
If some data packets are requested several times, each data packet counts separately
each time it is requested. For example, if three daemons request retransmission of data
packets numbered 121–125, then the Rseq sum is 15.
For more information, see Diagnoses on page 251.
Rrej Retransmission rejection notices.

Although Rendezvous daemons comply with retransmission requests whenever
possible, sometimes the requested packets are no longer available. This column
displays the number of packets that contain retransmission rejections.
Bad Bad packets.

some other way.

|
Diagnoses
Scanning for Problems on page 242 described a quick scanning technique for
locating problems in rvtrace output, looking for non-zero values in the Bad,
Gaps, and Rbytes columns of the multicast data tables. When such a scan
indicates problems, look more closely at the retransmit statistics in nearby
intervals.
Rseq measures retransmission requests for missed multicast or broadcast packets.
Non-zero Rseq values generally indicate a problem. The ratio Rdata/Data
measures the severity of the problem. Small ratios indicate low-level problems,
which you can investigate as time permits. Ratios of 2% or greater indicate
potentially serious network problems; investigate further. High ratios that last for
only one interval, could indicate an intermittent problem, which could become
more serious in other situations.
Notice that Rseq tabulates packets that serve a feedback mechanism within the
protocol. A data receiver becomes a feedback sender when it detects that it has
missed data packets. So the Rseq value in source rows indicates a data receiver
sending retransmission requests. Conversely, the Rseq value in destination rows
indicates a data sender receiving retransmission requests.
Consider the following two examples.
Difficulty at One Specific Receiver

Figure 54 on page 252 shows rvtrace output for three intervals, which indicate a
difficulty at one specific receiver. The administrator must investigate that receiver,
its network hardware, and its load.
Several situations could cause this pattern in rvtrace display output. For
example:
• One slow computer is flooded by too much data from a network of faster
senders; the receiver cannot process inbound data as fast as the rest of the
network.
• One receiver with intermittent network interface failures or a loose network
cable.

252
Figure 54 Rseq Reveals Difficulty at a Receiver

----- --------------- ------- --------- ----- ------- --------- ------ -----
Totals 989 311535 1 641 201959 9 0
7599 * 225.9.9.10 989 311535 1 641 201959 9 0
10.101.3.237 989 311535 0 640 201600 9 0
10.101.3.251 0 0 1 1 359 0 0

----- --------------- ------- --------- ----- ------
Totals 20 2222 0 0
7599 20 2222 0 0
* 10.101.3.74 0 0 0 0
4 7 0 0
* 10.101.3.237 20 2222 0 0
0 0 0 0
* 10.101.3.246 0 0 0 0
14 2211 0 0
* 10.101.3.251 0 0 0 0
2 4 0 0

----- --------------- ------- --------- ----- ------- --------- ------ -----
Totals 1000 315044 2 62 19530 0 0
7599 * 225.9.9.10 1000 315044 2 62 19530 0 0
10.101.3.237 999 314685 0 62 19530 0 0
10.101.3.246 1 359 2 0 0 0 0

----- --------------- ------- --------- ----- ------- --------- ------ -----
Totals 999 314685 2 0 0 0 0
7599 * 225.9.9.10 999 314685 2 0 0 0 0
10.101.3.237 999 314685 0 0 0 0 0
10.101.3.246 0 0 1 0 0 0 0
10.101.3.251 0 0 1 0 0 0 0
In Figure 54 on page 252, the first interval shows 9 sequence gaps in the multicast
data table—that is, 9 gaps in the stream of multicast packets. The Rseq column of
the multicast retransmit table contains further details; the host at address
10.101.3.246 requested 2211 packets for retransmission, while the other hosts
requested a total of 11 packets. Conclude that the locus of the problem is at
10.101.3.246, and that retransmit requests from the other receivers are side
effects.

|
The second interval of Figure 54 shows zero sequence gaps—the problem has
abated. Nonetheless, the Rdata and Rbytes columns indicate that retransmissions
continue as Rendezvous daemons recover from the problem by resending stored
data.
By the third interval of Figure 54, everything has returned to normal.
Difficulty at One Specific Sender

Figure 55 on page 254 shows output indicating a difficulty at one specific sender.
The administrator must investigate that sender, its sending applications, and its
network hardware.
Several situations could cause this pattern in rvtrace display output. For
example:
• The sender is flooding the network—that is, it is sending packets faster than
most other daemons on the network can receive them.
• The sender has intermittent network interface failures or a loose network
cable.
In Figure 55, the multicast data table shows 411 sequence gaps—that is, 411 gaps
in the stream of multicast packets. Moreover, all the missing packets originate at
one sender, 10.101.3.246. The Rseq column of the multicast retransmit table
contains further details; both of the receivers in the network requested those
packets for retransmission—that is 10.101.3.74 and 10.101.3.237 both sent
retransmit requests to 10.101.3.246. Conclude that the locus of the problem is at
10.101.3.246.
The Rdata column of the multicast data table shows that before the end of the
interval, the sender had retransmitted all 411 missing packets. The problem was a
brief glitch—the Rendezvous reliable transport mechanisms easily smoothed over
this temporary rough spot. Nonetheless, if such behavior recurs, the
administrator must investigate the problem.

254
Figure 55 Rseq Reveals Difficulty at a Sender

----- --------------- ------- --------- ----- ------- --------- ------ -----
Totals 588 185220 0 411 129465 411 0
7599 * 225.9.9.10 588 185220 0 411 129465 411 0
10.101.3.246 588 185220 0 411 129465 411 0

----- --------------- ------- --------- ----- ------
Totals 6 822 0 0
7599 6 822 0 0
* 10.101.3.74 0 0 0 0
3 411 0 0
* 10.101.3.237 0 0 0 0
3 411 0 0
* 10.101.3.246 6 822 0 0
0 0 0 0

Point-to-Point Statistics 255
|
Point-to-Point Statistics
Figure 56 shows a point-to-point (PTP) table (from rvtrace -addrinfo -ptp).

The text below introduces important concepts. Table 11 on page 256 describes the
columns in detail.
In switched ethernet environments point-to-point packets remain invisible to

rvtrace—except for packets addressed specifically to the rvtrace host
computer. Since this fact severely limits the usefulness of reporting point-to-point
statistics, rvtrace omits them from its output unless you specify the -ptp
command line option.
In some switched networks, you can disable switching behavior—for example, by
setting one port to diagnostic mode, or by using a diagnostic utility. This tactic can
yield the full stream of point-to-point packets in a limited portion of the network;
run rvtrace in that portion.
Figure 56 Point-to-Point Statistics
PTP Statistics
Port Address Data Bytes AckR Ack Nak Bad
----- --------------- ------- --------- ----- ------ ------- ------
Totals 8 1962 3 3 0 0
5090 8 1962 3 3 0 0
* 10.101.2.57 2 522 2 1 0 0
6 1440 1 2 0 0
* 10.101.3.72 6 1440 1 2 0 0
2 522 2 1 0 0
grand total of packets related to retransmission detected on the network during
the interval.
grouping them by UDP service, and destination or source IP address.
Port Subtotal Row The second row in Figure 56 is a port subtotal row—its columns subtotal the
statistics over the subsequent destination and source rows which it governs (until
the next port subtotal row).

256
A number in the Port column indicates the UDP service for its row, and the group
groups.
Destination and For each IP address with point-to-point data packet activity, this table contains a
Source Rows destination row and a source row—always paired in that order. An * and an IP
address (in the Address column) flags a row as a destination row. A blank (space
characters) flags a row as a source row. The address in the destination row also
applies to the source row that immediately follows it.
Counting Packets This table displays each packet twice—once in a destination row, and once in a
source row.
In each statistical column, the number in the port subtotal row is equal to the sum
of the values in the destination rows, which is also equal to the sum of the values
in the source rows.
In many networks it is possible to match the numbers in the source row for one IP
address against the numbers in the destination row for another IP address. From
this information you can deduce which Rendezvous daemons are exchanging
point-to-point data packets and requesting retransmissions.
Table 11 Point-to-Point Statistics—Column Headings (Sheet 1 of 2)

Column Description
Port In port subtotal rows, this column contains a UDP port number indicating the
In destination and source rows this column is blank; the service in the nearest
preceding port subtotal row governs the destination and source rows below it.
* Asterisk (*) in this unlabeled column indicates a destination row.

Address In destination rows this column shows the destination IP address of retransmission
request packets (that is, the Rendezvous daemon that originally sent data packets).
In source rows this column shows the IP address from which retransmission request or
rejection packets originate (that is, the Rendezvous daemon that missed receiving data
packets).

Point-to-Point Statistics 257
|
Table 11 Point-to-Point Statistics—Column Headings (Sheet 2 of 2)
Column Description
Data Point-to-point data packets.
This column shows the number of point-to-point data packets.
Bytes Point-to-point data bytes.

This column sums the number of payload bytes over the point-to-point data packets (as
counted in the Data column).
AckR Acknowledgement request packets.

Sending Rendezvous daemons explicitly request positive acknowledgment for groups
of point-to-point data packets. This column shows the number of packets containing
acknowledgment requests for point-to-point data packets.
Ack Acknowledgement packets.

Receiving Rendezvous daemons explicitly acknowledge groups of point-to-point data
packets upon request from sending daemons. This column shows the number of
packets containing acknowledgments for point-to-point data packets.
Nak Negative acknowledgement packets.

Receiving Rendezvous daemons use negative acknowledgments to request
retransmission of missing data point-to-point packets. This column displays the
number of packets containing retransmission requests for point-to-point data packets.
For more information, see Nak Diagnoses on page 257.
Bad Bad packets.

some other way.
Nak Diagnoses
Nak measures the number of point-to-point packets that request retransmission of
point-to-point data.
Non-zero Nak values to or from a specific address usually indicates one of these
problems:

258
• A faulty network interface card at a specific computer.

• A faulty or overloaded network infrastructure component (for example,
switching or router hardware).
• A fast sender is overwhelming a slower receiver with point-to-point packets.
• A sender on a fast network is overwhelming a network infrastructure
component by sending point-to-point packets to a receiver on a slower
network.
Begin by checking the specific interface card, and widen the investigation to other
components until you can resolve the difficulty.
Figure 57 displays example output with this pattern.

• The computer at address 10.101.3.246 is sending point-to-point data to
10.101.3.237.
• The AckR column shows that 10.101.3.237 received 68 requests for

acknowledgement to 10.101.3.246.
• The Nak column shows that 10.101.3.237 did not receive all the packets
correctly, and sent 23 NAKs back to 10.101.3.246. These NAKs constitute
retransmission requests for the missed point-to-point packets.
• The Ack column shows that eventually, 10.101.3.237 did receive all 68
retransmitted packets correctly, recovering from the problem.
• This particular example report does not contain sufficient information to
determine the locus of the problem—it could be either at the sender or the
receiver.
Figure 57 Nak Indicates Faulty Network Card or Infrastructure Component
PTP Statistics
Port Address Data Bytes AckR Ack Nak Bad
----- --------------- ------- --------- ----- ------ ------- ------
Totals 1716 597168 68 68 23 0
7599 1716 597168 68 68 23 0
* 10.101.3.237 1716 597168 68 0 0 0
0 0 0 68 23 0
* 10.101.3.246 0 0 0 68 23 0
1716 597168 68 0 0 0

Subject Statistics 259
|
Subject Statistics
The subject table counts multicast and broadcast messages (not packets) and
organizes statistics by Rendezvous subject name (in addition to UDP service and
destination address).
Figure 58 shows a subject table (from rvtrace -addrinfo). The text below
introduces important concepts. Table 12 on page 261 describes the columns in
detail.
Figure 58 divides the activity on UDP port 5090 into two subject names, and it
divides the activity on port 7500 into 10 subjects.
Figure 58 Subject Statistics—Multicast and Broadcast Data
Subject Statistics
----- --------------- ------- --------- -------
Totals 25 6462
10.101.3.67 1 359
5090 * 224.1.2.5 6 1242 sruga
10.101.3.72 6 1242
5090 * 224.1.2.5 4 1474 arug
10.101.2.57 2 728
10.101.3.72 2 746
7500 * 10.101.2.255 1 183 usia
10.101.2.66 1 183
7500 * 10.101.2.255 1 253 _RV.INFO.SYSTEM.HOST.START.0A650239
10.101.2.57 1 253
7500 * 10.101.2.255 1 339 _RV.INFO.SYSTEM.LISTEN.START.usia
10.101.2.57 1 339
7500 * 10.101.2.255 1 332 _RV.INFO.SYSTEM.LISTEN.START.cx.wove
10.101.2.66 1 332
7500 * 10.101.2.255 1 344 _RV.INFO.SYSTEM.LISTEN.START.ghoul
10.101.2.66 1 344
7500 * 10.101.2.255 1 327 _RV.INFO.SYSTEM.LISTEN.START.hurst
10.101.2.57 1 327
7500 * 10.101.2.255 1 339 _RV.INFO.SYSTEM.LISTEN.START.swart
10.101.2.57 1 339
7500 * 10.101.2.255 3 546 aryl.ding
10.101.2.66 3 546
7500 * 10.101.2.255 2 358 hurst
10.101.2.66 2 358
7500 * 10.101.2.255 2 366 swart
10.101.2.66 2 366
grand total of messages that rvtrace detected on the network during the interval.

260
The remaining rows display more fine-grained information about those

messages—grouping them by UDP service, destination address, subject name,
and source address.
Subject Subtotal A character string in the Subject column indicates the Rendezvous subject name
Groups for its row, and the group of rows that follow it. A blank in this column means
that the row has the same subject as the row above, and is part of the same
subtotal group. Notice how the pattern of subject names and blanks in the
Subject column visually indicates the subtotal groups. The visual pattern of
numbers in the Port column echoes this division.
Each subject subtotal group begins with a subject row (which is also a destination
row) followed by one or more source rows.
Destination and * flags a row as a destination row. A blank (space character) in this column flags a
Source Rows row as a source row.
Each destination row is the heading and subtotal for the source rows that follow
it. For example, consider the destination row with arug in the Subject column.
The Msgs column indicates 4 multicast messages. The two subsequent source
rows indicate that those 4 messages came from two sources—10.101.2.57 sent 2
messages, while 10.101.2.72 sent 2 messages. The subtotal 4 in turn contributes
to the grand total 25 in the network total row.
A subject row governs the source rows below it (until the next subject row). That is,
the subject, UDP service (port), and address in the governing row apply to those
source rows. Similarly, the governing row address implies either multicast or
broadcast protocol, and this protocol also applies to the statistics in the source
rows that it governs. (Naturally, all of this information also applies to the
governing row itself.)
Statistics In destination rows numbers in statistics columns count messages with the
destination specified in the Address column.
In source rows numbers in statistics columns count messages originating from the
IP address in the Address column.

Subject Statistics 261
|
In network total rows, numbers in statistics columns represent the message totals
for the network during the interval.
Table 12 Subjects Statistics—Column Headings
Column Description
Port In destination subtotal rows, this column contains a UDP port number indicating the
In source rows this column is blank; the service in the nearest preceding destination row
also applies to the source row.
* Asterisk (*) in this unlabeled column indicates a destination subtotal row.

Address In destination rows this column shows the destination address shared among a group of
messages. It can be an IP address or a multicast group.
In source rows this column shows the IP address from which group of messages
originate.
Msgs Rendezvous messages.

This column shows the number of messages that use multicast or broadcast protocols.
Bytes Data bytes.

This column sums the number of payload bytes over the messages (as counted in the
Msgs column).
Subject This column shows the Rendezvous subject name shared among the messages in a
subtotal group.
Subject Table Diagnoses

The subject table reveals interesting information about the subject name space,
and its use within the network:
• Programs that send messages in violation of the subject usage guidelines for
your enterprise
• Duplicate process instances of a sending program
• Subjects that consume large portions of network capacity

262
SNMP
rvtrace embeds an SNMP agent. You can use SNMP applications to query
rvtrace statistics and trap SNMP events (as listed in Table 13).
Table 13 SNMP Objects in rvTrace (Sheet 1 of 8)
Object Name Description

Network Totals
rvNetTotals Grouping for all network totals.
rvTrdpMCPktTotals Grouping for network totals related to multicast data packets.
rvTrdpMCDataPktTotal Total multicast or broadcast data packets.
rvTrdpMCDataByteTotal Total payload bytes in all multicast or broadcast data packets.
rvTrdpMCRtPktTotal Total multicast or broadcast retransmission packets.
rvTrdpMCRtByteTotal Total payload bytes in all multicast or broadcast retransmit packets.
rvTrdpMCNullPktTotal Total null packets.

When a Rendezvous daemon has no data packets to transmit, it
periodically sends null packets to maintain continuity.
rvTrdpMCSeqGapTotal Total Rendezvous packets that rvtrace missed.

rvtrace tracks the serial numbers of Rendezvous packets. This
object counts the missing packets in each sequence gap of multicast
or broadcast data packets. For more information, see Gaps
Diagnoses on page 247.
rvTrdpMCBadPktTotal Total bad multicast data packets.


SNMP 263
|

rvTrdpRtPktTotals Grouping for network totals related to retransmitted multicast or
broadcast packets.
rvTrdpRtReqPktTotal Total retransmission request packets.

Each request packet counts separately, even if several request
packets specify the same data packet numbers for retransmission.
For example, if two daemons each request retransmission of the data
packets numbered 121–125, and a third daemon requests
retransmission of the data packets numbered 100–144, then this total
increases by 3.
rvTrdpRtReqSeqTotal Total of requested sequence numbers summed over all

retransmission requests.
Each retransmission request packet can solicit one or more data
packets for retransmission. This object sums the number of data
packets for which retransmission is requested.
If some data packets are requested several times, each data packet
counts separately each time it is requested. For example, if three
daemons request retransmission of data packets numbered 121–125,
then this total increases by 15.
rvTrdpRtRejPktTotal Total retransmission rejections.

Although Rendezvous daemons comply with retransmission
requests whenever possible, sometimes the requested packets are no
longer available. This object counts the number of packets that
contain retransmission rejections.
rvTrdpRtBadPktTotal Total bad multicast retransmission packets.

rvPtpPktTotals Grouping for network totals related to point-to-point packets.
rvPtpDataPktTotal Total point-to-point data packets.
rvPtpDataByteTotal Total payload bytes in all point-to-point data packets.

264

rvPtpAckRPktTotal Total acknowledgement request packets.
Sending Rendezvous daemons explicitly request positive
acknowledgment for groups of point-to-point data packets. This
object counts the number of packets containing acknowledgment
requests for point-to-point data packets.
rvPtpAckPktTotal Total acknowledgement packets.

Receiving Rendezvous daemons explicitly acknowledge groups of
point-to-point data packets upon request from sending daemons.
This object counts the number of packets containing
acknowledgments for point-to-point data packets.
rvPtpNakPktTotal Total negative acknowledgement packets.

Receiving Rendezvous daemons use negative acknowledgments
(NAKs) to request retransmission of missing data point-to-point
packets. This column displays the number of packets containing
retransmission requests for point-to-point data packets.
For more information, see Nak Diagnoses on page 257.
rvPtpBadPktTotal Total bad point-to-point packets.

rvSubjectTotals Grouping for network totals related to Rendezvous subjects.
rvSubjMsgTotal Total number of messages (summed over all subjects).
rvSubjByteTotal Total number of payload bytes (summed over all subjects).
Thresholds
rvTrdpRtThreshold Threshold for retransmit trap.

When the ratio rvTrdpMCRtByteTotal/rvTrdpMCDataByteTotal
exceeds this threshold (expressed as a percentage), rvtrace sets the
SNMP trap rvTrdpNotifyRetransmit.
The default threshold is 2%.

SNMP 265
|

rvBadPktThreshold Threshold for bad packet trap.
When the number of bad packets during an interval exceeds this
threshold, rvtrace sets the SNMP trap rvNotifyBadPkts. Bad
packets of any type count toward this threshold.
The default threshold is zero—that is, trap even for one bad packet.
Multicast Host Snapshot
rvTrdpMCHostTable Table of multicast statistics, with one entry for each triple of sending
host (rvTrdpMCHostAddr), service port (rvTrdpMCPort), and
destination address (rvTrdpMCDestAddr).
rvTrdpMCPort Service port of packets counted in the table entry.
rvTrdpMCHostAddr IP address of the host that is the source of multicast or broadcast

packets counted in the table entry.
rvTrdpMCDestAddr Destination address of packets counted in the table entry. The

destination can be a multicast address or an IP (broadcast) address.
rvTrdpMCHostDataPkts Number of data packets for this triple.
rvTrdpMCHostDataBytes Number of payload bytes in data packets for this triple.
rvTrdpMCHostRtPkts Number of retransmission packets for this triple.
rvTrdpMCHostRtBytes Number of payload bytes in retransmission packets for this triple.
rvTrdpMCHostNullPkts Number of null packets for this triple.
rvTrdpMCHostSeqGaps Number of requested sequence numbers summed over all

retransmission requests for this triple.
packets for retransmission. This object sums the number of data
packets for which retransmission is requested.
rvTrdpMCHostBadPkts Number of bad multicast or broadcast packets for this triple.

266

Multicast Retransmission Host Snapshot
rvTrdpRtHostTable Table of multicast retransmission statistics, with one entry for each
pair of host (rvTrdpRtHostAddr) and service port (rvTrdpRtPort).
Entries in this table count several types of packets related to the
retransmission request protocol for multicast or broadcast data.
rvTrdpRtPort Service port of packets counted in the table entry.
rvTrdpRtHostAddr IP address of the host that is the source or destination of packets

counted in the table entry.
rvTrdpRtReqPktsSrc Number of retransmission request packets sent by the host (that is,
the host is the source of the request packet).
These packets indicate that the receiving Rendezvous daemon on the
host missed inbound data packets, and has requested
retransmission.
rvTrdpRtReqSeqSrc Number of data packet sequence numbers requested by the host

(that is, the host is the source of the request).
packets for retransmission. This item counts the number of data
packets for which the host requested retransmission, summing them
over the request packets (as counted by rvTrdpRtReqPktsSrc).
If the host requests some data packets several times, each data packet
counts separately each time the host requests it. For more
information, see Diagnoses on page 251.
rvTrdpRtRejPktsSrc Number of retransmission rejection notices sent by the host (that is,
the host is the source of the rejection packet).
requests whenever possible, sometimes the requested data packets
are no longer available.

SNMP 267
|

rvTrdpRtBadPktsSrc Number of bad retransmission request packets sent by the host (that
is, the host is the source of the bad packet).
rvTrdpRtReqPktsDest Number of retransmission request packets indicating the host as

destination.
These packets indicate that receiving Rendezvous daemons missed
data, and requested retransmission from the host.
rvTrdpRtReqSeqDest Number of data packet sequence numbers requested from the host.
packets for retransmission. This item counts the number of data
packets requested, summing them over the request packets (as
counted by rvTrdpRtReqPktsDest).
If several daemons request a data packet several times, each request
counts separately. For more information, see Diagnoses on page 251.
rvTrdpRtRejPktsDest Number of retransmission rejection notices indicating the host as

destination.
requests whenever possible, sometimes the requested data packets
are no longer available.
rvTrdpRtBadPktsDest Number of bad retransmission request packets indicating the host as

destination.

268

Point-to-Point Host Snapshot
rvPtpHostTable Table of point-to-point statistics, with one entry for each pair of host
(rvPtpHostAddr) and service port (rvPtpPort)
rvPtpPort Service port of packets counted in the table entry.
rvPtpHostAddr IP address of the host that is the source or destination of packets

counted in the table entry.
rvPtpPktsSrc Number of point-to-point data packets sent by the host (that is, the
host is the source of the data packet).
rvPtpBytesSrc Number of payload bytes summed over point-to-point data packets

sent by the host (that is, the host is the source of the data).
rvPtpAckRPktsSrc Number of packets requesting acknowledgement sent by the host

(that is, the host is the source of the acknowledgement request
packet).
rvPtpAckPktsSrc Number of ACK packets sent by the host.
rvPtpNakPktsSrc Number of NAK packets sent by the host.
rvPtpBadPktsSrc Number of bad packets sent by the host.
rvPtpPktsDest Number of point-to-point data packets indicating the host as

destination.
rvPtpBytesDest Number of payload bytes summed over data packets indicating the
host as destination.
rvPtpAckRPktsDest Number of acknowledgement request packets indicating the host as

destination.
rvPtpAckPktsDest Number of ACK packets indicating the host as destination.
rvPtpNakPktsDest Number of NAK packets indicating the host as destination.
rvPtpBadPktsDest Number of bad packets indicating the host as destination.

SNMP 269
|

Subject Snapshot
rvSubjTable Table of subject statistics, with one entry for each pair of subject
(rvSubject) and service port (rvSubjPort)
rvSubjPort Service port of messages counted in the table entry.
rvSubject Subject of messages counted in the table entry.
rvSubjMsgs Number of messages for this pair.
rvSubjBytes Number of payload bytes summed over messages for this pair.
Traps
rvtraceStart Notify when the SNMP agent in rvtrace starts.
rvtraceStop Notify when the SNMP agent in rvtrace stops.
rvTrdpNotifyRetransmit Notify when the ratio

rvTrdpMCRtByteTotal/rvTrdpMCDataByteTotal—expressed as a
percentage—exceeds rvTrdpRtThreshold.
rvNotifyBadPkts Notify when the number of bad packets during an interval exceeds
rvBadPktThreshold.
SNMP Agent Configuration

You can configure the agent and traps in the file rvtracesnmp.conf.
• On UNIX platforms, the configuration file is
/usr/local/etc/snmp/rvtracesnmp.conf
• On Windows platforms, the configuration file is /usr/rvtracesnmp.conf
Table 14 on page 270 presents the configuration parameters.

270
Table 14 SNMP Configuration Parameters
agentaddress <port> When present, the SNMP agent accepts requests and
queries on this port.
<port> can have either of two forms:
• 1234 (represents a UDP port)
• tcp:1234 (represents a TCP port)
When absent, the default port is 161.
informsink <host> [<community>] [<port>] When this line is present, the SNMP agent enables
trap objects, and sends trap notification to the
SNMP trap daemon on <host>.
When the optional <community> property is present,
the trap daemon must present an identical property
before it can receive trap notifications. The
<community> property must be a sequence of
alphanumeric characters (without quote marks, and
without intervening spaces).
When the optional <port> property is present, the
agent sends notifications on this port. The port can
have the same two forms as with agentaddress,
above. When absent, the default port is 162.
To send notification to several trap daemons, specify
a separate informsink line for each destination.
When informsink is absent, the agent disables trap
objects.

| 271
Chapter 12 Perl 5 Interface
Perl programs can call Rendezvous API functions directly using a Perl 5 loadable
module called Tibrv, which extends the Perl language.
Topics
• Features and Benefits, page 272

• Installing the Perl 5 Interface, page 273
• Using the Perl 5 Interface, page 274
• Perl Example Programs, page 275

272
| Perl 5 Interface
Features and Benefits
Tibrv presents the C API. All API details (for example, function names,
parameter lists, types, return codes) are the same as for C programs, so Perl
programmers can use it to:
• Prototype Rendezvous programs in Perl for later translation into C.
• Write Rendezvous programs in Perl.
System administrators often choose Perl for data organization tasks. Combining
Perl with Rendezvous software yields a powerful tool for:
• Gathering and organizing information about the operation of distributed
systems.
• Administering physically distant computers across a network.

Installing the Perl 5 Interface 273
|
Installing the Perl 5 Interface
For installation instructions, see the Rendezvous Perl README file:

<rv_installation_dir>/src/perl/README

274
| Perl 5 Interface
Using the Perl 5 Interface
Be sure that the library path variable is set properly; for instructions, see the
README file.
Place this module reference near the top of each Perl program file that calls
Rendezvous API functions:
use Tibrv;
If the program uses Rendezvous fault tolerance features, add this module
reference:
use TibrvFt;
If the program uses Rendezvous certified message delivery features or distributed

queues, add this module reference:
use TibrvCm;

Perl Example Programs 275
|
Perl Example Programs
The Rendezvous example directory (/src/examples/perl/) contains Perl

example programs.

276
| Perl 5 Interface

| 277
Chapter 13 Certified Message Delivery
Topics
• Forward RVCM Administrative Messages across Network Boundaries, page 278

• Ledger File Location, page 279

278
| Certified Message Delivery
Forward RVCM Administrative Messages across Network

Boundaries
Rendezvous certified message delivery software depends on administrative

announcements (as well as point-to-point messages) between CM transports.
These messages travel freely within a single network segment. However, if your
network consists of several segments connected by Rendezvous routing daemons,
then you must instruct the routing daemons to forward the subjects in Table 15.
Routing daemons must forward these subjects in both directions—import and
export.
Similarly, if clients in your network use SSL to connect to rvsd or rvsrd, you must
configure the secure daemon to authorize the subjects in Table 15.
Table 15 Critical Subjects for Certified Delivery
Subject Description
_RVCM.> Rendezvous certified delivery software uses administrative
messages with these subjects. Routing daemons must forward
these subjects in both directions.

Ledger File Location 279
|
Ledger File Location
The ledger file must reside on the same host computer as the program that uses it.
Do not use network-mounted storage for ledger files.
Remember that certified message delivery protects against component or network
failure. Placing ledger files across a network (for example, on a separate file
server) introduces a new dependency on the network, leaving components
vulnerable to network failures.

280
| Certified Message Delivery

| 281
Chapter 14 Fault Tolerance
Topics
• Network Placement, page 282

• Forward Fault Tolerance Messages across Network Boundaries, page 283

282
| Fault Tolerance
Network Placement
When you deploy a fault-tolerant application, it is important to distribute the

member processes appropriately across computers and across network segments.
Independence increases the effectiveness of redundant processes. For details, see
Distribute Members on page 222 in TIBCO Rendezvous Concepts.
It is also important to use files in a way that does not jeopardize fault tolerance.
For guidelines, see Member File Access on page 223 in TIBCO Rendezvous
Concepts.

Forward Fault Tolerance Messages across Network Boundaries 283
|
Forward Fault Tolerance Messages across Network Boundaries
Rendezvous fault tolerance software depends on messages between group

members, and on some Rendezvous system advisory messages.
Routing daemons must forward all these subjects in both directions—import and
export.
Table 16 Critical Subjects for Fault Tolerance
Subject Description
_RVFT.*.<group_name> Rendezvous fault tolerance software uses messages
with these subjects to communicate among group
members. Routing daemons must forward these
subjects in both directions.

284
| Fault Tolerance

| 285
Chapter 15 Distributed Queues
Topics
• Forward Administrative Messages across Network Boundaries, page 286

286
| Distributed Queues
Forward Administrative Messages across Network Boundaries
Rendezvous distributed queue software depends on administrative

announcements (as well as point-to-point messages) between distributed member
transports.
We do not recommend sending messages across network boundaries to a

distributed queue, nor distributing queue members across network boundaries.
However, when crossing network boundaries in either of these ways, you must
configure the Rendezvous routing daemons to exchange _RVCM and _RVCMQ
administrative messages.
Routing daemons must forward the subjects in Table 17 in both directions—

import and export.
Table 17 Critical Subjects for Distributed Queues (Sheet 1 of 2)
Subject Description
_RVCMQ.> Rendezvous distributed queue software uses administrative
messages with these subjects.
Whenever potential scheduler members run in one network, and
potential listener members of the same distributed queue run in a
second network, then routing daemons must forward these
subjects in both directions between the two networks.
Similarly, whenever potential listener members of the same
distributed queue run in two separate networks, then routing
daemons must forward these subjects in both directions between
the two networks.
_RVCM.> Rendezvous distributed queue software uses administrative

Whenever a process in one network sends task messages to
potential scheduler members in a second network, then routing
daemons must forward these subjects in both directions between
the two networks.

Forward Administrative Messages across Network Boundaries 287
|
Table 17 Critical Subjects for Distributed Queues (Sheet 2 of 2)
Subject Description
_RVFT.> Rendezvous distributed queue software uses administrative
Whenever potential scheduler members of the same distributed
queue run in two separate networks, then routing daemons must
forward these subjects in both directions between the two
networks.

288
| Distributed Queues

| 289
Appendix A Windows Services
You can run Rendezvous components automatically by registering them as

Microsoft Windows services. This appendix describes two utility programs to
arrange registration.
Topics
• rvntscfg, page 290

• rvntsreg, page 291
See Also
Register NT Services on page 8

290
| Windows Services
rvntscfg
Utility
Purpose Graphical user interface to configure Rendezvous components as Windows

services.
Restrictions You must have administrator privileges to change the Windows registry.
Remarks Locate this utility program as an executable file in the Rendezvous bin\ directory.
Rendezvous components belong to one of two categories:
• Base communications components. This category consists of rvd and rvrd—
the two components that enable network communications.
• Dependent components. All other components are in this category—they
depend on the presence of a base communications component.
Before you can start one of these programs as a service, one of the base
communications components must already be running as a service.
Register To register a component as a Windows service:

1. Start rvntscfg.exe.
2. Select the Rendezvous component.
3. Specify manual or automatic start. In most cases, the appropriate choice is
automatic—that is, start the component automatically when starting Windows.
4. Check the path to the Rendezvous bin\ directory (or the correct location of
the component).
5. Check the arguments to the program.
In particular, ensure that this field correctly specifies the store file and HTTP
access.
6. Click the Install button to register, or the Update button to change an existing
registration.
7. When prompted to start the new service, click Yes.
Remove To unregister a service:

1. Start rvntscfg.exe.
2. Select the Rendezvous component.
3. Click the Remove button to unregister the service.

rvntsreg 291
|
rvntsreg
Utility
Purpose Register Rendezvous components as Windows services.
Restrictions You must have administrator privileges to change the Windows registry.
Remarks Locate this utility program as an executable file in the Rendezvous bin\ directory.
The rvntscfg utility achieves the same end as this program, adding an intuitive
graphical user interface.
Register To register a component as a Windows service, run the utility with this command
line:
rvntsreg /i <service_name> <directory> <arguments>
For example:
rvntsreg /i rvrd C:\tibco\tibrv\bin\ "-store
C:\tibco\tibrv\adm\rvrd.adm"
Remove To unregister a service, run the utility with this command line:
rvntsreg /r <service_name>
Command To view a command line summary, run the utility with this command line:
Summary rvntsreg
See Also rvntscfg on page 290

292
| Windows Services

| 293
Appendix B Changes in Release 6
Rendezvous release 6 introduced many important changes, which carry forward

to later releases. This appendix summarizes the differences that directly affect
system and network administrators.
Licensing
Release 6 simplified license administration. For complete information, see
Licensing Information on page 11.
Transports
The concept of a session is obsolete. However, the concepts of service, network
and daemon (formerly arguments to session initialization calls) transfer to
transport objects.
Command Line Parameters and Browser Interface

In all Rendezvous process components, we have replaced the command line
interface with a web browser interface based on HTTP. For most parameters, the
transition is intuitive.
Routing Daemon
Many important details of the routing daemon changed for release 6 (and later).
For complete information, see Routing Daemon (rvrd) on page 57.
rvcache
In earlier releases, programs automatically received initial values based on
subscription advisories. In release 6 (and later) programs must explicitly query by
subject for the most recent data.
For details, see Current Value Cache on page 181.

294
| Changes in Release 6

| 295
Index
A C
accept any as neighbor, rvrd 72 cache 181–193
Ack column, rvtrace 257 capture file, rvtrace 231
AckR column, rvtrace 257 certificate, security factor 135
active neighbor, rvrd 71 certified delivery
address routing daemons 277
Address column, rvtrace 246, 250, 256, 261 rvperf 214, 220
filter, rvtrace 233, 234 rvperfm parameters 207
information, rvtrace 236 rvperfs parameters 210
administrator name and password 108, 152 checklist for administrators 1
administrator’s checklist 1 checksum 6
advisory message client socket, daemon parameter 28
See also, the book TIBCO Rendezvous Concepts cm, See certified delivery
and, boolean filters, rvtrace 240 cm-sync, rvperf parameter 207, 211
applet, Java 177 collision, rvperfm 204
authorization, secure daemon 133 core dump file, security factor 135
auto, rvperfm parameter 206 current value cache 181–193
automatic mode, rvperf 198, 199, 206 customer support xx
B D
backlog, routing 88 daemon parameter 18, 28
Bad column, rvtrace 247, 250, 257 rvperfm 205
barring remote connections 29 rvperfs 210
batch daemon, rvd 35–42
interval, rvperfm parameter 207 data capture file, rvtrace 231
size, rvperfm parameter 207 Data column, rvtrace 246, 257
batch, rvperf 197 usage 241
binary executable files 4 data loss advisory, rvperf 200
boolean operators in filters, rvtrace 240 default port and service numbers 30
broadcast filter, rvtrace 240 destination filter, rvtrace 235
Bytes column, rvtrace 246, 257, 261 distributed queues and routing daemons 285
usage 241 dividing large messages, rvperf 221
duplicate messages from rvcache 185

296
|
E hardware, gauging capabilities, rvperf 217

host filter, rvtrace 239
elapsed time, rvperf 215 hostmsgs, rvtrace parameter 237
errors 238 HTTP, default ports 30
execution search path 4
I
F
idle
fault tolerance rva 172
rvcache 188 rvcache 191
rvrd 74 rvrd 89
rvrd serving FT programs 281 inbox, rvperfm parameter 206
feedback source and destination, rvtrace 251 independent routes 77
file descriptor limit 9 input file, rvtrace parameter 233, 234
filter installation, See the book TIBCO Rendezvous
details, rvtrace 239 Installation
parameter, rvtrace 235 interface
pcap, rvtrace 230 network, rvtrace 227
firewalls rvtrace parameter 232
rva 177 interpreting the report
rvrd 85 rvperf 212
fixed subject interest, rvrd (obsolete) 68 rvtrace 241
flush time, rvperf 215 interval between batches, rvperf 197
-foreground, rvtrace parameter 237 rvperfm parameter 207
interval, update, rvtrace parameter 236
IP filter, rvtrace 240
G
Gaps column, rvtrace 246 J
diagnosing 247
gating, subject Java applet 177
rva 170
rvrd 66
H lead wildcards, excluding 39

ledger file, rvperf 220
h (help) rvperfm parameter 207
rvperfm parameter 208 rvperfs parameter 210
rvperfs parameter 211
rvtrace parameter 237

| 297
license 11–16 network parameter 18, 23
installing 3 multicast addressing 25
purchasing 16 rvperfm 205
ticket file 13 rvperfs 210
limitations network stress, warning, rvperf 216
rvtrace 227 -no-display, rvtrace parameter 236
limits -no-lead-wc, rvd option 39
performance assessment, warning 222 no-mcast, rvtrace parameter 236
-listen parameter 28 -no-multicast 39, 94
load, assessing, rvtrace 241 no-subjects, rvtrace parameter 237
local network, rvrd 66 not, boolean filters, rvtrace 240
local port, rvrd 69 Null column, rvtrace 246
-logfile, rvtrace parameter 237
logging, rvrd 90
-log-rotate, rvtrace parameter 237
O
open file limit 9
M optimal sustained receive rate, rvperf 217
or, boolean filters, rvtrace 240
maximum backlog, routing 88 output file, rvtrace parameter 236
maximum throughput, rvperf 199
merge, rvcache 189
message size, rvperf 206
very large 221 P
messages, rvperfm parameter 206
metered protocol 201 packet
mode, rvperf 198 capture file, rvtrace 231, 233, 234, 236
automatic, operational narrative 199 checksum 6
Msgs column, rvtrace 261 filtering, rvtrace 230, 239
multicast addressing 25 passive monitor, rvtrace 229
multicast filter, rvtrace 240 passive neighbor, rvrd 71
multicast, disabling 39, 94 password, administrator 108, 152
password, security factor 135
path 4
pause between batches, rvperf 197
N payload data, rvperf 197
pcap, rvtrace 230
Nak column, rvtrace 257 performance assessment tool (rvperf) 195–223
usage 257 principles of operation 197
navigation panel 146 performance effects, rvtrace, warning 229
negative acknowledgement 201 performance obstacles, locating, rvperf 223
neighbor, rvrd 69 Perl 271–275
network filter, rvtrace 239 PGM and TRDP, bridging networks 87
network interface (-i), rvtrace parameter 232 PGM default network 23

298
|
physically secure environment 135 routing daemon 57–125
platform support, rvtrace 228 and certified delivery 277
point-to-point messages 206 and distributed queues 285
point-to-point, rvtrace parameter 237 with fault-tolerant applications 283
Port column, rvtrace 245, 249, 256, 261 routing table entry 65
port filter, rvtrace 235, 240 Rrej column, rvtrace 250
port number, UDP or PGM 21 Rreq column, rvtrace 250
defaults 30 Rseq column, rvtrace 250
positive acknowledgement 201 usage 251
prerequisites, rvtrace 226 run length, rvperf 206
process identification, rvperf 214 rva 169–180
prohibiting remote connections 29 command summary 170
promiscuous mode, rvtrace 229, 238 idle 172
protocol 201 rvcache 181–193
protocol filter, rvtrace 240 command summary 189
protocol monitor 225–261 fault tolerance 188
ptp, rvtrace parameter 237 idle 191
with rvrd 187
_RVCM.> (administrative subjects) 277, 286
_RVCMQ.> (administrative subjects) 286
R rvd 35–42
command summary 36
rate _RVFT.> (administrative subjects) 283, 287
optimal, rvperf 217 rvntsreg 8
rvtrace parameter 237 rvperf 195–223
raw storage device, as rvcache store file 190 rvperfm command 204
Rbytes column, rvtrace 246 rvperfs command 209
Rdata column, rvtrace 246 rvrad 165–168
read packets from file, rvtrace 233, 234 command summary 166
register Windows NT service 8 rvrd 57–125
relay agent 165–168 accept any as neighbor 72
reliability parameter 41 active neighbor 71
remote port, rvrd 69 command summary 92
Rendezvous agent 169–180 fault tolerance 74
Rendezvous daemon 35–42 idle 89
Rendezvous routing daemon 57–125 independent routes 77
replace, rvcache 189 logging 90
report maximum backlog 88
interpreting rvperf 212 passive neighbor 71
interpreting rvtrace 241 seek neighbor with any name 72
retention time and reliability 41 topology errors 82
retransmit diagnoses, rvtrace 251 with fault-tolerant applications 283
router name with rvcache 187
See also, Routing table entry rvsd 127
command line 139

| 299
rvsrd 127 T
command line 142
rvtrace 225–261 TCP, default ports 30
command reference 232 technical support xx
throughput, maximum, rvperf 199
tibrv.tkt (license ticket file) 13
too many open files (OS error) 9
S TRDP and PGM, bridging networks 87
-save-rotate, rvtrace parameter 236

search path 4
secondary effects, rvperf 222 U
secure daemon 127
differences from non-secure behavior 137 UDP filter, rvtrace 240
security factors 135 UDP or PGM, default services 30
seek neighbor with any name, rvrd 72 unmetered protocol 201
sequence gap, rvtrace 247 update interval, rvtrace parameter 236
service, NT 8 user, secure daemon 131
service, UDP or PGM
defaults 30
defining services 5
parameter 18, 20 V
rvperfm 205
rvperfs 209 very large messages, rvperf 221
single mode, rvperf 198, 206
size, rvperf
batch 197
message 206 W
SNMP objects in rvtrace 262
-snmp, rvtrace parameter 237 WAN, rvperf 219
socket limit 9 warning
source filter, rvtrace 233, 234 limits of performance assessment 222
store file, security factor 135 network stress, rvperf 216
subject performance effects, rvtrace 229
rvperfm parameter 206 security factors 135
rvperfs parameter 210 web site 177
Subject column, rvtrace 261 wide-area network, rvperf 219
subject gating wide-area routing daemon (rvrd) 57–125
rva 170 wildcard, excluding subjects with lead wildcards 39
rvrd 66 Windows, register NT service 8
subject interest, rvrd 62 write packets to file, rvtrace 236
subjects, administrative 283
support, contacting xx
switched networks, rvtrace 227
sync ledger file, rvperf 207, 211

300
|

RV Administration

Uploaded by

Copyright:

Available Formats

RV Administration

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RV Administration

Uploaded by

Copyright:

Available Formats

What is the purpose of the document?

What is the purpose of the document?

What are some of the main topics covered in the document?

What are some of the main topics covered in the document?

TIBCO Rendezvous™

Chapter 1 Do This First—Administrator’s Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 2 Licensing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

TIBCO Rendezvous Administration

Chapter 3 Network Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Chapter 4 Rendezvous Daemon (rvd). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Chapter 5 Routing Daemon (rvrd). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

TIBCO Rendezvous Administration

TIBCO Rendezvous Administration

Chapter 6 Secure Daemons (rvsd and rvsrd) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

TIBCO Rendezvous Administration

Chapter 7 Relay Agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Chapter 8 Rendezvous Agent (rva) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

TIBCO Rendezvous Administration

Chapter 9 Current Value Cache. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Chapter 10 Performance Assessment (rvperf) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

TIBCO Rendezvous Administration

Chapter 11 Protocol Monitor (rvtrace) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Chapter 12 Perl 5 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

TIBCO Rendezvous Administration

Chapter 13 Certified Message Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

Chapter 14 Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Chapter 15 Distributed Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Appendix A Windows Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

Appendix B Changes in Release 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

TIBCO Rendezvous Administration

TIBCO Rendezvous Administration

TIBCO Rendezvous Administration

Table 1 Specify UDP or PGM Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

TIBCO Rendezvous Administration

TIBCO Rendezvous Administration

This manual explains administration of TIBCO Rendezvous™ software and the

• Manual Organization, page xvi

TIBCO Rendezvous Administration

This book begins with important information for system administrators:

The next several chapters describe Rendezvous components that run as

Many administrators use the Perl programming language for system

Additional administrative tasks apply when distributed systems use advanced

TIBCO Rendezvous Administration

To register Rendezvous software with the Microsoft Windows operating system,

Architectural changes in release 6 lead to several important changes for

TIBCO Rendezvous Administration

This section lists documentation resources you may find useful.

TIBCO Product Documentation

TIBCO Rendezvous Administration

• TIBCO Rendezvous Administration

TIBCO Rendezvous Administration

How to Contact TIBCO Customer Support

TIBCO Rendezvous Administration

Chapter 1 Do This First—Administrator’s Checklist

This checklist outlines several important tasks for system administrators.

• Install the Rendezvous Software, page 2

TIBCO Rendezvous Administration

Install the Rendezvous Software

Install Rendezvous software at your site. The book TIB/Rendezvous Installation

TIBCO Rendezvous Administration