TIBCO Rendezvous Network Server Administration

TIBCO Rendezvous® Network ServerAdministrationSoftware Release 1.1March 2015

Two-Second Advantage®

Important Information

SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCHEMBEDDED OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY(OR PROVIDE LIMITED ADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THEEMBEDDED OR BUNDLED SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANYOTHER TIBCO SOFTWARE OR FOR ANY OTHER PURPOSE.

USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS ANDCONDITIONS OF A LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTEDSOFTWARE LICENSE AGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THECLICKWRAP END USER LICENSE AGREEMENT WHICH IS DISPLAYED DURING DOWNLOADOR INSTALLATION OF THE SOFTWARE (AND WHICH IS DUPLICATED IN THE LICENSE FILE)OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT OR CLICKWRAP END USERLICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE “LICENSE” FILE(S) OF THESOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, ANDYOUR USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BEBOUND BY THE SAME.

This document contains confidential information that is subject to U.S. and international copyright lawsand treaties. No part of this document may be reproduced in any form without the writtenauthorization of TIBCO Software Inc.

TIBCO, Two-Second Advantage, TIBCO Rendezvous and TIBCO FTL are either registered trademarksor trademarks of TIBCO Software Inc. in the United States and/or other countries.

Enterprise Java Beans (EJB), Java Platform Enterprise Edition (Java EE), Java 2 Platform EnterpriseEdition (J2EE), and all Java-based trademarks and logos are trademarks or registered trademarks ofOracle Corporation in the U.S. and other countries.

All other product and company names and marks mentioned in this document are the property of theirrespective owners and are mentioned for identification purposes only.

THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOTALL OPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASEDAT THE SAME TIME. SEE THE README FILE FOR THE AVAILABILITY OF THIS SOFTWAREVERSION ON A SPECIFIC OPERATING SYSTEM PLATFORM.

THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.

THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICALERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESECHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCOSOFTWARE INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S)AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANY TIME.

THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY ORINDIRECTLY, BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE,INCLUDING BUT NOT LIMITED TO ANY RELEASE NOTES AND "READ ME" FILES.

Copyright © 1997–2015 TIBCO Software Inc. ALL RIGHTS RESERVED.

TIBCO Software Inc. Confidential Information

2

TIBCO Rendezvous® Network Server Administration

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

About this Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

TIBCO Documentation and Support Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Introduction to TIBCO Rendezvous® Network Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Backward Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Installing Fault-Tolerant Network Servers—Task Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Zones & Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Creating a Rendezvous Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Zone Configuration File (trns.conf) Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Updating a Zone to a New Software Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Backing Up and Restoring a Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Zone Administration Utility Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Operating System Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Service Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

Service Script Default Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Overriding Service Script Parameter Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Administrative Directories Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

Redundancy & Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

VRRP Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

Virtual Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

VNIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Rendezvous Fault Tolerance in Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Zone Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Recovery and Failback after Zone Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Circumventing Client Failback after the Preferred Zone Recovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

Zone Configuration for Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Operational Modes of the Virtual Router Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

Active-Active Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Establishing Active-Active Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Verifying Active-Active Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Active-Standby Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Establishing Active-Standby Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3


Verifying Active-Standby Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Client Reconnection during Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Rendezvous Gateway Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Gateways Route Messages among Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Gateway Operation and States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Comparison of rvgd with rvrd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Gateway Concepts and Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

Gateway Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Service Groups and Gateway LAN Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

Gateway Local Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Multicast Local Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Subject Gating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Redundancy and the Gateway—Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

Redundant Gateways, No Multicast Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Configuring Redundant Gateways, No Multicast Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Normal Gateway Operation, No Multicast Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

Failover Behavior, No Multicast Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Redundant Gateways, Multicast Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Configuring Redundant Gateways, Multicast Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

Normal Gateway Operation, Multicast Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Failover Behavior, Multicast Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Adapter: Communication between Rendezvous and FTL Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Adapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Adapter Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47

Adapter Start Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Adapter FTL Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Adapter Rendezvous Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Configuring the Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Adapter Configuration Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

Adapter Administration: Realm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54

Adapter Data Type Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Data Type Mapping: FTL to Rendezvous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Data Type Mapping: Rendezvous to FTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Data Type Mapping Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Request Reply Interactions through the Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

Primary FTL Request, Secondary Rendezvous Reply to an Inbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Secondary Rendezvous Request to an Inbox, Tertiary FTL Reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Primary Rendezvous Request to a Subject, Secondary FTL Reply to an Inbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Rendezvous Subjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Adapter Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4


Commands Reference Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Zone Administrative Commands Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

VRRP Commands Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

Service Administrative Commands Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62

5


Figures

Reduce Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

VRRP and Rendezvous Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Active-Active Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Active-Standby Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

Gateway Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Configuring Local Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Gateway Configuration, Fault Tolerance, No Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Gateway Operation, Fault Tolerance, No Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Gateway Failover, Fault Tolerance, No Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Gateway Configuration, Fault Tolerance, Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Gateway Operation, Fault Tolerance, Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Gateway Failover, Fault Tolerance, Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

6


About this Product

TIBCO® is proud to announce the latest release of TIBCO Rendezvous® Network Server software.

This release is the latest in a long history of TIBCO products that leverage the power of InformationBus® technology to enable truly event-driven IT environments. To find out more about how TIBCORendezvous Network Server software and other TIBCO products are powered by TIB® technology,please visit us at www.tibco.com.

7


HTTP://WWW.TIBCO.COM/

TIBCO Documentation and Support Services

All TIBCO documentation is available on the TIBCO Documentation site, which can be found here:

https://docs.tibco.com

Product-Specific Documentation

Documentation for TIBCO products is not bundled with the software. Instead, it is available on theTIBCO Documentation site. To directly access documentation for this product, double-click thefollowing file:

TIBCO_HOME/release_notes/TIB_trns_version_docinfo.html

The following documents for this product can be found on the TIBCO Documentation site:

● TIBCO Rendezvous Network Server Installation● TIBCO Rendezvous Network Server Administration● TIBCO Rendezvous Network Server Glossary

For detailed information about TIBCO Rendezvous, see the documentation set for that product.

Third-Party Documentation

For details about the hardware host system, see documentation from Pluribus Networks.

For details about operating system commands, refer to operating system documentation (man pages)located on the hardware host.

For a general discussion of VRRP, see the article in Wikipedia.

How to Contact TIBCO Support

For comments or problems with this manual or the software it addresses, contact TIBCO Support asfollows:

● For an overview of TIBCO Support, and information about getting started with TIBCO Support,visit this site:

http://www.tibco.com/services/support

● If you already have a valid maintenance or support contract, visit this site:

https://support.tibco.com

Entry to this site requires a user name and password. If you do not have a user name, you canrequest one.

How to Join TIBCOmmunity

TIBCOmmunity is an online destination for TIBCO customers, partners, and resident experts. It is aplace to share and access the collective experience of the TIBCO community. TIBCOmmunity offersforums, blogs, and access to a variety of resources. To register, go to:

https//www.tibcommunity.com

8


https://docs.tibco.com

http://www.tibco.com/services/support

https://support.tibco.com

Audience

TIBCO Rendezvous® Network Server Administration is intended for system administrators andexperienced users who are familiar with IP network configuration.

9


Prerequisites

TIBCO assumes these prerequisite conditions for the tasks in this document:

● You have a functioning IP network.● You and your TIBCO sales representative have determined the correct number and placement of the

TIBCO Rendezvous Network Server hardware systems you require.● These TIBCO Rendezvous Network Server hardware systems have been or will be installed in an

equipment rack and at least minimally configured by network administrators who are responsiblefor installing and setting up network equipment.

10


Introduction to TIBCO Rendezvous® Network Server

TIBCO Rendezvous Network Server software provides TIBCO Rendezvous® message semantics andRendezvous daemon functionality.

Client Connections

From the perspective of Rendezvous client applications, TIBCO Rendezvous Network Server acts as aremote daemon. Clients connect to TIBCO Rendezvous Network Server using TCP/IP.

Use CasesTIBCO Rendezvous Network Server can reduce complexity in an existing Rendezvous network.

This diagram illustrates one possible scenario.

Reduce Complexity

Multicast Bandwidth

You can eliminate or reduce multicast bandwidth consumption.

In the diagram, each network server completely replaces a multicast domain. Hybrid arrangements,which connect multicast domain clients with network server clients, are also possible.

Large-scale multicasting imposes complex requirements on network topology and sizing. Reliabledelivery uses additional bandwidth for retransmission.

TIBCO Rendezvous Network Server provides the same delivery semantics as network multicasting, butimplements those semantics using switching hardware. As a result, TIBCO Rendezvous NetworkServer reduces network infrastructure and bandwidth usage without affecting Rendezvous clientapplications.

Server Consolidation

You can consolidate server hardware to reduce real estate and power consumption.

11


The diagram illustrates one way that a pair of redundant network servers can replace many servers.

Fault Tolerance

You can simplify fault-tolerant communications for application programs.

Network servers use virtual routers to manage redundant services, so each client process can connect toits fault-tolerant daemon at only one virtual IP address. In the diagram, red dashed lines indicatefailover paths.

ClientsYou can either employ TIBCO Rendezvous Network Server as your complete Rendezvousenvironment, or you can connect it to an existing Rendezvous environment.

Client applications connect to a network server as if to a remote rvd. (For details, see the programminglanguage reference books in the Rendezvous documentation set.)

● When all clients connect to the network server, you can completely eliminate network multicasttraffic.

● When integrating TIBCO Rendezvous Network Server with an existing Rendezvous environment(in which applications connect to daemons), application transports in the existing environment stillcommunicate using network multicast, but clients of the network server do not.

Backward CompatibilityFor best results, build client applications using the most recent release of Rendezvous software.Nonetheless, TIBCO Rendezvous Network Server can interoperate with clients built using previousreleases of Rendezvous software back to Release 5.

Rendezvous Release 6 and Later

As a provider of Rendezvous 8 functionality, TIBCO Rendezvous Network Server is compatible withRendezvous Releases 8, 7 and 6 in all respects (except for features that are new or obsolete).

Rendezvous Release 5

TIBCO Rendezvous Network Server and Rendezvous Release 5 can interoperate, subject to theselimitations.

(For more information about compatibility among Rendezvous releases, see Compatibility with EarlierReleases in TIBCO Rendezvous Concepts.)

● TIBCO Rendezvous Network Server accepts connections from programs compiled and linked withthe Rendezvous Release 5 API.

● TIBCO Rendezvous Network Server can interoperate with rvd from Release 5.

● Rendezvous gateway daemon of TIBCO Rendezvous Network Server and an rvrd process fromRelease 5 cannot establish a neighbor connection.

● Nonetheless, rvrd processes from Release 5 can coexist in the same network as the Rendezvousgateway daemon of TIBCO Rendezvous Network Server.

12


Installing Fault-Tolerant Network Servers—Task OverviewTo quickly prepare a new network server for use in a redundant arrangement for fault tolerance,complete these administrative tasks. (Links to the tasks are for your convenience.)

Procedure

1. Install the software module.See TIBCO Rendezvous Network Server Installation

2. Create the Rendezvous zone.See Creating a Rendezvous Zone.

3. Configure the hardware switch.See TIBCO Rendezvous Network Server Installation.

4. Configure gateway daemons.See:

● Configuring Redundant Gateways No Multicast Clients● Configuring Redundant Gateways Multicast Clients

13


Zones & Services

TIBCO Rendezvous Network Server isolates Rendezvous activity within a Rendezvous zone (virtualmachine). Within a zone, services manage the daemon processes that provide Rendezvousfunctionality.

ZonesA zone is a light-weight (that is, a low-overhead) virtual machine.

In its original factory configuration, the hardware host for TIBCO Rendezvous Network Server has onedefault zone, called the global zone. You cannot delete the global zone.

Administrators use the global zone to configure a separate Rendezvous zone, where the Rendezvousfunctionality operates, on the server side of the host machine (which is server switch hardware). Thezone administration utility, trnsadmin, can create a Rendezvous zone and assign physical resources toit for its exclusive use, such as a physical network interface. The zone administration utility also createsand configures software resources within the Rendezvous zone, such as operating system services andcommand line scripts to manipulate them.

Because each Rendezvous zone has exclusive use of a physical network interface, you can segregateRendezvous production network traffic from management traffic.

Creating a Rendezvous ZoneAfter installing a TIBCO Rendezvous Network Server module, administrators must create aRendezvous zone using the trnsadmin utility.

Prerequisites

● Verify that the TIBCO Rendezvous Network Server software module has been installed on thehardware host. To install, see TIBCO Rendezvous Network Server Installation.

● Designate a unique zone name for each zone in your enterprise.● Designate a unique IP address (UIP) for each zone that you will configure.

For example, if you plan to configure two zones (one on each of two hardware hosts), designate twounique IP addresses, and assign one to each zone.

● Designate two virtual IP addresses (VIP), which become the basis of redundancy for fault tolerance.● Determine the preferred zone for each VIP; for background information, see Operational Modes of

the Virtual Router Pairs.● Determine the failback behavior for failover clients after zone recovery.

After clients failover from the preferred zone to a non-preferred backup zone, and the preferredzone subsequently becomes available again, two behaviors are possible:

● Clients automatically failback to the preferred zone. Failback is the default behavior.● Clients do not failback, and remain connected to the non-preferred zone. You must configure

this behavior explicitly.

Procedure

1. Login to the global zone.a) Use ssh to login as admin to the hardware host.b) Run pfexec bash to start a shell with root privileges.

14


2. Prepare the configuration file.a) Copy the template configuration file /opt/tibco/trns/version/etc/trns.conf.b) In a text editor, modify your private copy.c) Insert one of the unique IP addresses that you designated (as a pre-requisite).

When configuring zones on separate hardware hosts (for fault tolerance), insert the unique IPaddresses you assigned (as a pre-requisite) to this zone.

d) Insert the two virtual IP addresses that you designated (as a pre-requisite).e) Set the preferred zone parameters for the two VIPs. If this zone is the preferred zone for a VIP,

set the corresponding parameter to True. If the other zone is preferred, set it to False.

For example, for active-active mode, configure these values in the first zone: "vip1_preferred":true "vip2_preferred":false

When you configure the second zone, use the boolean inverses of these values. "vip1_preferred":false "vip2_preferred":true

In contrast, for active-passive mode, configure the first zone with both values set to True(active), and the second zone with both values set to False (passive).

For background information, see Operational Modes of the Virtual Router Pairs.f) Set the enable_client_failback parameter for the zone.

For details, see Zone Setup Configuration File Reference.g) Save your modifications.

3. Create the zone by running the zone administration utility: /opt/tibco/trns/version/bin/trnsadmin --create filename

In this command, supply the file path to your private copy of the configuration file.

Do not interrupt the utility.

4. Verify the zone.a) Log in to the zone:

zlogin zonename

After a Rendezvous zone has been created, you can log in to it from the global zone at any time.b) Review all interfaces:

ifconfig -a

Verify that the physical interface ixgbe1 is plumbed with the zone’s unique IP address.

Verify that the zone has two VNIC interfaces with prefix rv (for example, rv0 and rv1), and theyare plumbed with the two shared virtual IP addresses.

c) Review all the data-links (that is, physical interfaces, VNICs and VLANs): dladm show-link

d) Verify that the VRRP service is in the online state: svcs vrrp

e) Review the VRRP configuration: vrrpadm show-router

Verify that each virtual router is associated with the correct VNIC.f) Verify that the MCP service is enabled, and services rvgd64-A-idle and rvgd64-B-idle are

enabled in the idle state. svcs tibco-trns

15


What to do next

● Repeat this task to create other zones, as needed.● Configure gateway daemons:

— Configuring Redundant Gateways No Multicast Clients— Configuring Redundant Gateways Multicast Clients

● Physically connect the client network to the hardware.

Zone Configuration File (trns.conf) ReferenceAdministrators arrange the zone configuration file, trns.conf, to guide the zone adminstration utilityas it creates a zone.

The zone configuration file is in JSON format.

Parameter Description

zonename Name of the zone.

This name must be unique throughout the enterprise network.

uip Unique IP address of the zone.

vip1

vip2

Two virtual IP addresses of the zone; see Zone Configuration forFault Tolerance.

vip1_preferred

vip2_preferred

For each VIP, designate exactly one zone as its preferred home, thatis, the zone where you prefer that this VIP operates.

To designate a preferred zone for a VIP, set the correspondingparameter to true in the preferred zone, and set it to false in theopposite zone. For example, if you prefer that VIP_A operate onzone 1, set vip1_preferred to true when configuring zone 1, andset vip1_preferred to false when configuring zone 2.

You must explicitly set both of these parameters in each zone.

Zone preferences translate into initial priority values of virtualrouters.

gateway Optional.

Default gateway.

If your network has a default gateway, you may supply its IPaddress as the value of this parameter.

This type of gateway is not related to the TIBCORendezvous gateway daemon. Rather, it refers to ageneral networking feature. When networking softwarecannot resolve a route to an IP address, it uses the defaultgateway address instead.

16



dns_domain

dns_nameserver_primary

dns_nameserver_secondary

Optional.

DNS configuration

You can use these parameters to configure DNS for the zone toenable hostname resolution.

Set dns_domain to the default domain name.

Set the nameserver parameters to to IP addresses of the DNSnameservers.

enable_client_failback Optional.

This parameter governs behavior when clients have failed over tobackup daemons in this zone, and the opposite zone hassubsequently recovered.

When true, clients migrate back to the opposite zone.

When false, clients remain with this zone.

If absent, the default value is true.

vip1_adapter_config

vip2_adapter_config

Optional.

If this zone runs daemons with the adapter module to enablecommunication between Rendezvous and FTL applicationprograms, supply the adapter configuration file name as the valueof this parameter.

When a zone uses two VIPs, you can include an adapter for zero,one or both VIPs.

For more information, see Adapter: Communication betweenRendezvous and FTL.

vip1_rvd_cmdline

vip2_rvd_cmdline

vip1_rvgd_cmdline

vip2_rvgd_cmdline

Optional.

You may supply command line parameters to the daemon scripts.When a daemon script starts a daemon, it appends one of thesestrings to the daemon's command line.

For more information about daemon command line parameters,see TIBCO Rendezvous Administration.

Updating a Zone to a New Software ReleaseYou can update a zone to a newer release of TIBCO Rendezvous Network Server software, modify thezone configuration, or update the command line arguments of services within a zone.

The release number of the zone administration utility automatically determines the release number ofthe update software. For example, a utility from Release 1.1.0 always updates the zone to Release 1.1.0.

You cannot downgrade to an earlier release.

Prerequisites

The new software must be installed in the global zone.

17


Procedure


2. Run the zone administration utility: /opt/tibco/trns/version/bin/trnsadmin --update zonename

Do not interrupt the utility.

Result

Zone update automatically does these steps:

1. Halt.

The utility halts all processes in the zone. Clients failover to the opposite zone (if fault tolerance isenabled).

2. Update.

The utility copies updated software from the global zone to the Rendezvous zone.

3. Regenerate.

The utility regenerates all files that were created when the zone was created, such as daemon scriptsand hostname files.

These new files supercede the older versions of those files, overwriting any changes thatyou might have made to those files.

If you have modified parameter values in the zone reference configuration file /var/tibco/stores/trns.conf, then those new values become part of the regenerated scripts.

4. Reboot.

The utility reboots the zone.

Unless the zone’s enable_client_failback parameter is False, the new zone resumes operation,and clients migrate back to it from the opposite zone.

Backing Up and Restoring a ZoneYou can use the zone administration utility to back up the configuration of zone to a zip file. You canuse that zip file to restore (that is, recreate) the zone, either on the same host or a different host.Zone backup can be an important part of your backup assurance, disaster recovery, and host migrationprocedures. TIBCO support staff might request a zone backup archive while assisting you with asupport inquiry.

Prerequisites

Backup and restore operations are available starting with Release 1.1.0.

Procedure


18


2. Back up the zone.trnsadmin --backup zonename

This operation creates a zip archive named zonename.zip in the current working directory. Thisarchive contains a zone reference configuration, the adapter configuration files (if any), and copiesof all store files and TIBCO Rendezvous daemon log files from the zone.

3. Destroy the existing zone.trnsadmin --destroy zonename

4. Optional. Copy the zone archive to a different host.If you are moving the zone to a different host, copy the zip archive to that host. Login to the globalzone on that host (repeating step 1), and continue with the next step there.

5. Restore the zone.trnsadmin --restore zonename

This recreates the zone with the same configuration, ready to resume service.

Zone Administration Utility ReferenceYou can use the zone administration utility to create or delete a Rendezvous zone.

The zone administration utility is trnsadmin. It is located in /opt/tibco/trns/version/bin.

Do not interrupt the utility while it is executing. Interruption could result in partially configuredVNICs. The only way to clear such anomalies is to reboot the hardware host.

The zone administration utility must run in the global zone, and requires root privileges. To arrangethis environment, log in to an account with administrator privileges, and then run the commandpfexec bash.

The default administrator account is admin. If you create other administrator accounts, you mustspecify the correct role (-R) and profile (-P), for example:useradd -m -d /export/home/tibco -g 2000 -P 'Primary Administrator' -R 'root' -s /bin/bash tibco

Syntax

trnsadmin [-c filename | --create filename] | [-d zonename | --destroy zonename] | [-u zonename | --update zonename] | [-b zonename | --backup zonename] | [-r zonename | --restore zonename] [-v | --verbose] [-h | --help] [--version]

Parameters


-h

--help

When present, output the help message for the utility,and exit immediately.

-c filename

--create filename

Create a new zone using the configuration values infilename.

-d zonename

--destroy zonename

Destroy the zone.

19



-u zonename

--update zonename

Update the zone to use a new release of TIBCORendezvous Network Server software.

For details, see Updating a Zone to a New SoftwareRelease.

-b zonename

--backup zonename

Back up the zone.

For details, see Backing Up and Restoring a Zone.

-r zonename

--restore zonename

Restore the zone; that is, recreate the zone from abackup zip archive.

For details, see Backing Up and Restoring a Zone.

-v

--verbose

Output verbose, unformatted diagnostic output.

--version When present, output the version number of theutility, and exit immediately.

Operating System ServicesWithin a zone, services manage the daemon processes that provide Rendezvous functionality.

In a fault-tolerant arrangement, each zone contains five Rendezvous services of three types (see thetable below).

Rendezvous Services

Type Number Description

rvd64 2 Rendezvous daemon.

The zone administration utility defines one daemon service correspondingto each of the two virtual routers.

Network clients connect to these daemons through shared virtual IPaddresses.

These daemons disable multicast, so they support only a hub-and-spokenetwork with the daemon as hub, and clients as spokes. To extend messagerange to multicast networks, use the gateway daemon.

rvgd64 2 Rendezvous gateway daemon.

The zone administration utility defines one gateway service correspondingto each of the two virtual routers.

Gateways can move messages to other networks, including networksassociated with other network servers, as well as multicast networks.

MCP 1 Master Control Program.

MCP controls the states of the other Rendezvous services in the zone, basedon the states of the zone’s VNICs.

20


Service ScriptsThe network server uses a script to start each Rendezvous service (rather than starting the executablebinary directly). Each script defines the command line for its service, based on parameters you set inthe zone configuration file.

These scripts are located under /opt/tibco/trns/version/bin.

Service Script Default ValuesThe zone administration utility configures the Rendezvous service scripts with default parametervalues.

Rendezvous Service Default Parameter Values

Service Name --http --listen --store

rvd64-A 43000 vip_A:7500

rvd64-B 43001 vip_B:7501

rvgd64-A

rvgd64-A-idle

43002 /var/tibco/stores/rvgd64_A.store

rvgd64-B

rvgd64-B-idle

43003 /var/tibco/stores/rvgd64_B.store

You can override these and other default values by configuring command line parameters; see Overriding Service Script Parameter Values.

● All HTTP ports are on the zone’s unique IP address (UIP). You may override the port number, butnot the IP address.

● rvd services specify --no-multicast. You cannot override this flag.

● rvgd services specify --http-only.

● The default reliability for gateway daemons is 5 seconds. For rvd services, reliability is not relevant,because they do not allow multicast.

● File name stems for log files and store files are based on the service name.● Unless otherwise noted here, you may override the documented parameters of rvd and rvrd.

However, the service scripts also supply values for parameters that are specific to rvgd, which arenot documented; do not attempt to override any of these parameter values.

Overriding Service Script Parameter ValuesYou can override service script default values by supplying additional command line options. Supplythese parameter values when you configure the zone. For example, you can change the defaultreliability or listen ports of the Rendezvous daemons.

Do not modify service scripts directly. Updating or destroying a zone deletes the existing servicesscripts, and any modifications to those scripts are lost.

Do not override any parameters of the rvgd services that are not documented as parameters of rvrd.(See rvrd documentation in TIBCO Rendezvous Administration.)

21


Procedure

1. Open the appropriate configuration file for editing.

Option Description

Creating a new zone. Edit your private copy of the configuration file trns.conf.

Modifying an existing zone. Edit the zone reference configuration file /var/tibco/stores/trns.conf in place. It is good practice to make a backup copyfirst.

Both documented and undocumented parameters can appear inthe reference configuration file. Do not edit undocumentedconfiguration parameters.

2. Override parameters analogously in corresponding Rendezvous service scripts in cooperatingzones.See vip1_rvd_cmdline in Zone Configuration File (trns.conf) Reference.Ensure that corresponding services are still compatible.For example, in the zone administration utility, you could override the rvd listen port:"vip1_rvd_cmdline":"--listen VIP_A:12000"

3. Apply the new parameter values.

Option Description

Creating a new zone. Complete the task Creating a Rendezvous Zone.

Modifying an existing zone. Complete the task Updating a Zone to a New Software Release.

For more detail, see also Zone Administration Utility Reference.

What to do next

Repeat this task as needed for the opposite zone in a fault-tolerant pair.

Log FilesEach daemon writes a log file in /var/tibco/logs/service_name.log.

Service scripts specify these default values:

● Log file name, based on the service name● Maximum size of each log file, 2MB● Maximum number of rotations, 5 files

You may modify these values by supplying command line parameters for the service scripts; see Overriding Service Script Parameter Values.

For details about Rendezvous log file rotation, see TIBCO Rendezvous Administration.

22


Administrative Directories ReferenceTIBCO Rendezvous Network Server software uses file system directories for output and storage. TheRendezvous zone mounts these directories.

Administrative Directories

Directory Description

/var/tibco/logs Log files.

/var/tibco/cores Core dump files.

/var/tibco/stores rvgd store files.

23


Redundancy & Fault Tolerance

TIBCO Rendezvous Network Server can operate in redundant pairs for fault tolerance.

VRRP BasicsTIBCO Rendezvous Network Server software uses the Virtual Router Redundancy Protocol (VRRP, seeIETF RFC 3768) to implement fault tolerance for Rendezvous functionality. This topic describes only thesubset of VRRP that you need when using TIBCO Rendezvous Network Server software.

Virtual RoutersEach virtual router has a virtual router ID (VRID). Virtual routers with the same VRID are de factomembers of a group. When virtual routers in the same group share a common LAN, they cancommunicate with one another (over the unique IP address) using VRRP, and cooperate for faulttolerance.

A virtual router in a network server zone uses the zone’s unique IP address to communicate with theother member of its VRID group. The other member operates within another zone on a separatenetwork server host.

When an administrator enables a virtual router, it joins its VRID group.

When enabled, a virtual router can be in either of two running states—master or backup. At any momentonly one virtual router in a VRID group can be in the master state—the other group member is in thebackup state. Virtual routers in a group communicate to elect one member as the master.

Each virtual router has a priority parameter. When a VRID group elects a master, the relative priorityvalues determine which member becomes the master—namely, the virtual router with the greatestpriority from among those that have joined the group.

When you create a zone, you configure the preferred zone of VIPs. This configuration determines theinitial priority values of the corresponding virtual routers. You can explicitly modify these priorities tochange the operating mode behavior (see Operational Modes of the Virtual Router Pairs).

VNICA virtual router can manage one or more virtual network interfaces (VNICs). The zone administrationutility configures each VNIC with a virtual IP address (VIP), which is different from the router’s uniqueIP address (UIP).

Virtual routers in the same VRID group share the same set of virtual IP addresses, but at any momentonly one VNIC is in the up state (namely, the VNIC within the virtual router that is in the master state).That VNIC becomes the logical destination for its virtual IP address; that is, communication traffic onthat virtual IP address flows only through the VNIC that is up.

Meanwhile, all other VNICs that share that virtual IP address are in the down state.

24


Rendezvous Fault Tolerance in ActionTIBCO Rendezvous Network Server uses virtual routers to implement redundancy for fault tolerance.This extended example illustrates the redundancy model; related documentation topics refer back to it.

VRRP and Rendezvous Fault Tolerance

The diagram illustrates a typical arrangement of two network hosts configured for fault-tolerantoperation in active-active mode (see Active-Active Mode). Zone 1 is a virtual machine on host 1. Zone 1contains two virtual routers, VR-1.A and VR-1.B. VR-1.A manages virtual IP address A, and VR-1.Bmanages virtual IP address B.

Zone 2 is similarly configured on host 2. VR-2.A manages virtual IP address A, and VR-2.B managesvirtual IP address B.

Notice that corresponding VNICs within VR-1.A and VR-2.A share virtual IP address A. Analogously,VNICs within VR-1.B and VR-2.B share virtual IP address B.

Solid borders indicate that VR-1.A and VR-2.B are in the master state. Conversely, dashed bordersindicate that VR-1.B and VR-2.A are in the backup state.

The corresponding VNICs are either up (solid border) or down (dashed border), each following thestate of its managing virtual router. That is, at the moment depicted in the diagram, the VNIC in zone 1with virtual address A is up. Therefore, the VNIC in zone 2 with virtual address A is down. Allnetwork traffic on address A flows through zone 1.

Conversely, the VNIC in zone 2 with virtual address B is up, while the VNIC in zone 1 with virtualaddress B is down. All network traffic on address B flows through zone 2.

25


Master Control Program (MCP)

Each Rendezvous zone runs a service called the master control program (MCP), which controls otheroperating system services in the zone. The MCP monitors the state of the zone’s VNICs, and enablesRendezvous services accordingly.

When a virtual router enters the master state, its VNIC enters the up state, and the MCP enables theRendezvous daemon service on the corresponding virtual IP address. Conversely, when a virtualrouter enters the backup state, its VNIC enters the down state, and the MCP disables the Rendezvousdaemon on the corresponding virtual IP address.

For example, in zone 1 of the diagram (above), while VNIC A is in the up state, MCP arranges forRVD 1.A to run, and for RVGD 1.A to be in the active state (both indicated by solid borders). WhileVNIC B is in the down state, MCP arranges for RVD 1.B to not run, and for RVGD 1.B to be in the idlestate (both indicated by dashed borders).

The MCP in zone 2 arranges for the opposite state of affairs.

Clients

The diagram (above) also depicts Rendezvous clients within the network. Each client connects to adaemon at one of the two virtual IP addresses—A or B. The VNIC in zone 1 with address A is up, so allthe A clients connect to RVD 1.A. The VNIC in zone 2 with address B is up, so all the B clients connectto RVD 2.B.

Zone Failover

Suppose host 1 stops operating, or a network segmentation makes zone 1 unreachable. The diagram(below) illustrates the situation at failover.

26


Failover

The virtual routers in zone 2 detect that their counterparts in zone 1 are no longer available. Inparticular, VR-2.A responds by transitioning to the master state (solid border), since VR-1.A can nolonger play that role. The VNIC in zone 2 with virtual IP address A transitions to the up state.

When MCP in zone 2 detects this state change, it starts RVD 2.A, and arranges for RVGD 1.A totransition from the idle state to the active state.

Clients that connect to a daemon at address A automatically reconnect to RVD 2.A.

Meanwhile, nothing changes for virtual router B, its VNIC with address B, and the B daemons. RVD 2.Bcontinues to serve the B clients.

Recovery and Failback after Zone FailoverWhen a zone recovers after failover, a chain of events determines the behavior of clients.Administrators can affect this behavior when configuring the zones, and also dynamically.

When zone 1 returns after failover, each VRID group elects a member as the master. One virtual routerenters the master state, while the other enters the backup state. MCP arranges the appropriateRendezvous services corersponding to VIP A, and A clients failback based on virtual IP address.

You can affect the election in two ways: when configuring the zone, and dynamically:

● Configuration: The zone configuration parameter enable_client_failback governs behavior ofthe backup zone when clients have failed over to its backup daemons, and the opposite zone hassubsequently recovered.

— When True (the default behavior), clients failback to the preferred zone for the VIP.

27


— When False, clients do not failback to the preferred zone for the VIP. (To achieve this result, thefailover zone boosts the virtual router priority).

● Dynamic: You can override the configured behavior by explicitly adjusting the virtual routerpriority at the failover zone. However, the adjustment must take effect before the preferred zonerecovers, so this intervention is feasible only when you explicitly halt and boot the preferred zone. Itis not feasible when the zone fails and recovers independently of the administrator.

For example, if host 1 requires further analysis, administration or maintenance before resumingnormal operation, you can temporarily arrange for zone 2 to be the preferred zone for both VIPs (asin the diagram Active-Standby Mode). Afterward, you can re-establish fault-tolerant operation (asin the diagram Active-Active Mode).

To adjust priorities, see Establishing Active-Standby Mode, and Establishing Active-Active Mode.

Circumventing Client Failback after the Preferred Zone Recovers

You can circumvent client failback by explicitly establishing active-standby mode before normalrecovery can occur. Even if the zone's enable_client_failback parameter is True, you can explicitlyoverride this behavior changing zone priority values.

For example, if host 1 requires further analysis, administration or maintenance before resuming normaloperation, you can temporarily arrange for zone 2 to be the preferred zone for both VIPs (as in thediagram Active-Standby Mode). Afterward, you can re-establish fault-tolerant operation (as in thediagram Active-Active Mode).

Procedure

Task A: Establish Active-Standby Mode

1. Complete the task Establishing Active-Standby Mode.

Task B: Re-establish Active-Active Mode

2. Complete the task Establishing Active-Active Mode.

Zone Configuration for Fault ToleranceComplementary zones cooperate for fault tolerance. Administrators use the zone administration utilityto configure complementary zones on two TIBCO Rendezvous Network Server hosts.

When configuring a pair of complementary zones, administrators assign each zone a unique IP address.In addition, administrators reserve two shared virtual IP addresses.

The zone administration utility creates two virtual routers within a zone. Each virtual router has itsown VNIC, associated with one of the shared virtual IP addresses. Rendezvous Fault Tolerance inAction describes the way that virtual routers cooperate to route communications on those virtual IPaddresses to one of the two zones.

Operational Modes of the Virtual Router Pairs

Active-Active ModeWhen two zones cooperate in active-active mode, each zone actively services a different and disjoint setof Rendezvous clients. An active-active arrangement can provide fault tolerance while sharing theclient load.

The diagram depicts two zones in active-active mode. Zone 1 runs a Rendezvous daemon that servicesclients on virtual IP address A, while zone 2 runs a Rendezvous daemon that services clients on virtualIP address B.

28


The clients divide themselves into two disjoint sets based on the IP address where each client connectsto a Rendezvous daemon. (Each client specifies its daemon IP address in the create transport call.)

Active-Active Mode

Establishing Active-Active Mode

You can explicitly establish active-active mode by modifying the virtual router priority.

TIBCO Rendezvous Network Server implements preferred zones using the priority parameter ofvirtual routers in VRRP. Priority 200 indicates a preferred zone, and priority 100 indicates a non-preferred zone.

Prerequisites

This task description assumes that you have explicitly established active-standby mode by boosting thepriority of routerA on zone 2 (see Establishing Active-Standby Mode). If instead you have boosted thepriority of routerB on zone 1, modify the task step accordingly.

Procedure

● To allow VIP_A to return to zone 1, reset the priority of routerA on zone 2 to 100 (restoring thesituation before you established active-standby mode): vrrpadm modify-router -p 100 routerA

29


Verifying Active-Active Mode

After establishing active-active mode, verify that the services are in the appropriate states.

Procedure

● Verify the states of Rendezvous services in each zone by comparing the output of this command withthe table below: svcs tibco-trns

Service Status in Active-Active Mode

Service Zone 1 State Zone 2 State

rvgd64-A Enabled Idle

rvgd64-B Idle Enabled

rvd64-A Enabled Enabled

rvd64-B Enabled Enabled

Active-Standby ModeIn active-standby mode, one zone actively services clients on both virtual IP addresses, while the otherzone does not serve any clients. That is, by establishing active-standby mode, you deliberately arrangefor all clients to migrate to one zone. You can use active-standby mode when performingadministrative tasks on one of the host machines.

Active-standby mode (this diagram) is similar to a zone failover situation (compare the diagram Failover)—even though zone 1 is still operating and reachable.

Zone 2 runs Rendezvous daemons that service clients on virtual IP addresses A and B, respectively.Meanwhile, the Rendezvous services in zone 1 do not serve any clients.

The clients still divide themselves into two disjoint sets based on the IP address where each clientconnects to a Rendezvous daemon. However, this distinction does not tie the clients to separate zones.

30


Active-Standby Mode

Establishing Active-Standby Mode

You can explicitly establish active-standby mode by modifying the virtual router priority.For example, if host 1 requires analysis, administration or maintenance, you can temporarily arrangefor zone 2 to be the preferred zone for both VIPs (as in the diagram Active-Standby Mode). Afterward,you can re-establish fault-tolerant operation (as in the diagram Active-Active Mode).

TIBCO Rendezvous Network Server implements preferred zones using the priority parameter ofvirtual routers in VRRP. Priority 200 indicates a preferred zone, and priority 100 indicates a non-preferred zone.

Prerequisites

Procedure

● To hold VIP_A on zone 2 (even though zone 1 is operating), boost the priority of routerA on zone 2to a value greater than 200; for example, 210: vrrpadm modify-router -p 210 routerA

What to do next

When host 1 is ready to resume active duty, complete the task Establishing Active-Active Mode.

31


Verifying Active-Standby Mode

After establishing active-standby mode, verify that the services are in the appropriate states.

Procedure

● Verify the states of Rendezvous services in each zone by comparing the output of this command withthe table below: svcs tibco-trns

This table reflects a situation in which zone 1 is standby and zone 2 is active (as in the diagram Active-Standby Mode). If instead zone 1 is active and zone 2 is standby, then reverse the zone statecolumns.

Service Status in Active-Standby Mode

Service Zone 1 State Zone 2 State

rvgd64-A Idle Enabled

rvgd64-B Idle Enabled

rvd64-A Disabled Enabled

rvd64-B Disabled Enabled

Client Reconnection during FailoverClient reconnection during failover and failback is automatic. No explicit action is required byapplication programmers. Rendezvous clients automatically reconnect to the same IP address, andcannot distinguish between daemons in the two zones.

Failover preserves inbox names (because inbox names are keyed to the IP address). Clients continue toreceive point-to-point messages at the same inbox names.

The failover sequence appears to a client application as a transient TCP disconnect:

During failover, the Rendezvous client transport presents an RVD.DISCONNECTED advisory.

TCP disconnect causes a Rendezvous application to reconnect.

When the virtual router and MCP complete their failover sequence, the client transport automaticallyconnects to the daemon in the operational zone. The client cannot detect any change.

When reconnected, the client transport presents an RVD.CONNECTED advisory, and messages continue toflow as before.

During the period between disconnect and reconnect, data loss can occur (without specific DATALOSSadvisories).

For details about these advisories, see TIBCO Rendezvous Concepts

32


Rendezvous Gateway Daemon

The Rendezvous gateway daemon routes messages among networks so that otherwise isolated clientscan communicate.

When reading documentation about the gateway daemon, it is important to distinguish these similar-sounding terms:

Virtual Routeris an operating system entity, which does not require explicit configuration.

Gateway Router (also called rvgd router)is a TIBCO process, which does require explicit configuration.

Gatewayrefers to gateway LANs, gateway daemons and gateway clients.

Subject Gatingis a configurable aspect of routing daemons and gateway daemons with respect to their LANs.

Gateways Route Messages among NetworksRendezvous gateway daemons enable communication among clients on different networks associatedwith TIBCO Rendezvous Network Servers, and with Rendezvous clients on other networks. Considerthese examples.

Gateway Daemon to Route between Disjoint Sets of Clients

The example in Rendezvous Fault Tolerance in Action shows two groups of clients (A and B)connecting to Rendezvous daemons at two virtual IP addresses. All the A clients can communicate withone another, and all the B clients can communicate with one another, but these two sets of clientsremain isolated from one another. Gateway daemons can route between the networks associated withthe two virtual IP addresses.

Gateway Daemon to Route with Multicast Local-Area Networks (LANs)

An enterprise could use TIBCO Rendezvous Network Server to serve some clients (network A), withother Rendezvous clients connecting to local Rendezvous daemons that communicate using multicasttechnology (network M). The gateway can route between these two networks, allowing the A and Mclients to communicate.

Gateway Daemon to Route with Wide-Area Networks (WANs)

While the other network could be nearby, as in the previous example, it could also be distant. Thegateway daemon can create neighbor connections to rvgd and rvrd instances on distant networks,allowing communication with their clients too.

Gateway Operation and StatesGateway daemons run as operating system services within Rendezvous zones.

A redundant configuration includes two gateway daemons—one corresponding to each virtual router.

Rendezvous gateway daemons have two operational states—running and idle. A gateway daemon’sstate is tied to the state of the corresponding virtual router and VNIC.

● When running, the gateway daemon establishes neighbor connections and routes messages. Thebrowser administration interface is also available for configuring parameters.

33


When a virtual router is in the master state, MCP arranges for the corresponding gateway daemonto be in the running state.

● When idle, the gateway daemon neither routes messages nor establishes neighbor connections.However, the browser administration interface is available for configuring parameters.

When a virtual router is in the backup state, MCP arranges for the corresponding gateway daemonto be in the idle state.

Comparison of rvgd with rvrdThe Rendezvous gateway daemon (rvgd) implements the full functionality of a Rendezvous routingdaemon (rvrd), plus additional gateway functionality.

In its gateway role, an rvgd process connects (as a client) to an rvd at the shared virtual IP address. Asa client of that rvd, it can exchange messages with other clients. Its rvrd functionality lets it exchangemessages with other networks.

The gateway role is the focus of documentation related to this product (TIBCO Rendezvous NetworkServer); for aspects related to rvrd functionality, see rvrd documentation in TIBCO RendezvousAdministration.

Interoperability and Compatibility

The gateway daemon interoperates seamlessly with rvrd. (However, rvgd cannot establish neighborconnections with rvrd from Rendezvous release 5.)

The gateway daemon is available for TRDP only—it is not available for PGM.

The default reliability value for the rvgd is 5 seconds (in contrast, the default for daemons inRendezvous distribution packages is 60 seconds).

Clients

Application clients cannot connect to rvgd as they would to rvd or rvrd, because rvgd listens for clientconnections only on the loopback interface (and Rendezvous application programs are not permitted torun on the network server host).

Iin the context of the gateway daemon, the term client refers to a Rendezvous client transport connectedto some other daemon process.

Configuration

To configure the a gateway daemon, use its browser administration interface. (For details, see rvrd inTIBCO Rendezvous Administration, because the rvgd browser administration interface is similar to thatof rvrd).

34


Gateway Concepts and TerminologySeparate terms denote three categories of Rendezvous client transports that can communicate throughrvgd (and which could not intercommunicate without it). Each client category corresponds to a type ofnetwork.

Client Type Network Type

Gateway ClientGateway clients connect to an rvd servicewithin TIBCO Rendezvous Network Server ata shared virtual IP address. rvgd cancommunicate with gateway clients because ittoo is a client of that same rvd service.

Communication among gateway clients usessubject-based multicast technology within thenetwork server host. It does not result inmulticast packets on the network.

Gateway LANA gateway LAN is a local network associatedwith a shared virtual IP address. This networkconsists of an rvd service within a TIBCORendezvous Network Server, and itsconnected Rendezvous clients.

Multicast ClientMulticast clients communicate using the IPmulticast capabilities of Rendezvous software.

Rendezvous clients that connect to an rvd onthe same network as the zone’s unique IPaddress are multicast clients. So are clienttransports that use TIBCO Rendezvous® In-Process Module to multicast on that network.rvgd can communicate with multicast clientsbecause it is a routing daemon, and thatnetwork is one of its local networks.

Multicast LANA multicast LAN is a local network that isaccessible through the zone’s NIC and uniqueIP address. A gateway daemon can have zeroor more multicast LANs, as needed, to connectmulticast clients with gateway clients.

Client of a NeighborClients of neighbors can communicate becauseRendezvous routing daemons forward theirmessages over neighbor links. Those clientscould be gateway clients of another rvgd, ormulticast clients on another network.

Corresponding to these three client categories,administrators configure rvgd to routemessages among networks of three types:

Neighbor NetworkA neighbor network is a separate networkconnected by a neighbor link to another routerinstance. A gateway daemon can have zero ormore neighbor networks, as needed.

Gateway Routing Daemon

This diagram (below) illustrates the gateway daemon routing among these three types of networks andtheir Rendezvous clients.

35


Gateway Daemon

Gateway LAN

The gateway LAN is depicted in green in the diagram (above). The ability to configure gateway LANsis one feature that distinguishes rvgd from rvrd.

Without the gateway, clients of RVD communicate only with one another. They would not be able tocommunicate with clients of any other daemon.

Configuring a gateway LAN is similar to configuring an rvrd local network, with an additional checkbox to enable gateway functionality. Supply the same service and network specifications as the otherclients of RVD.

Notice that rvgd is a client of RVD within a specific Rendezvous service group. Each service group thatmust communicate beyond RVD requires a separate gateway LAN.

Multicast LAN

A multicast LAN is depicted in black in the diagram (above), indicating rvgd support for this use case.However, multicast LANs are optional, and many enterprises prefer to eliminate them.

Configure a multicast LAN as you would configure a local network of an rvrd.

Neighbor Link

The diagram (above) shows a neighbor link in blue. The other router could be an instance of either rvrdor rvgd. It could be on the same host machine, a nearby host machine, or geographically distant.

Configure neighbor links as you would configure neighbor links among rvrd instances. You mayconfigure neighbor links between rvgd and rvrd.

When configuring neighbor links to a router that is one of a redundant pair, remember to include bothrouters of the pair as neighbors.

36


Gateway ConfigurationTo configure the Rendezvous gateway daemon, use its browser administration interface, whichbehaves the same as the rvrd interface—except for the additional ability to configure gateway LANs.

Access the browser administration interface at this URL: http://zone_unique_IP_addr:http_port

For a list of the default HTTP port numbers where you can configure the gateway daemons, see ServiceScript Default Values.

Service Groups and Gateway LAN InterfacesTIBCO Rendezvous documentation uses the term service group to refer to a group of Rendezvoustransport objects that specify equivalent service and network parameters. Equivalent parameters enablethem to share messages with one another.

For each service group configure a separate gateway LAN, with service and network parameterscorresponding to those of of the service group.

rvd processes within a Rendezvous zone always specify the -no-multicast flag, so they do not useUDP protocols nor IP multicast groups. Instead, the network server routes messages among rvd clientsusing specialized hardware. Nonetheless, that hardware emulates the semantics of UDP services and IPmulticast groups; that is, the service and network parameters of client transports still governcommunication among clients (even though no multicast packets flow over the network).

Gateway Local NetworkA gateway local network interface lets a service group of gateway clients communicate with multicasttransports.

You can configure a gateway local network interface in rvgd. The network and service parameters ofthe gateway local network must match those of the gateway clients. Configure one local network in thegateway for each service group of gateway clients.

To configure a gateway local network interface, enable the Gateway check box when adding a localnetwork interface.

Configuring Local Networks

To navigate to this screen, see Routing Daemon (rvrd): Local Network Interfaces Configuration, inTIBCO Rendezvous Administration.

Network Specification Field

When you configure the network specification of a gateway local network interface, do not specify part1.

37


Recall that part 1 of the 3-part network specification determines the hardware interface through whichdata flows into and out of a gateway daemon’s local network. In a TIBCO Rendezvous Network Serverhost these interfaces are fixed, so rvgd overrides this part of the network specification—using onlyparts 2 and 3 (IP multicast information).

(Rendezvous documentation describes the 3-part network specification—network, multicast groupsand send address. For complete background information, see Network Selection in TIBCO RendezvousAdministration.)

Multicast Local NetworkA local network interface lets a service group of multicast transports communicate with gateway clients.

You can configure a local network interface in rvgd. The network and service parameters of themulticast local network must match those of the multicast transports.

Each service group of multicast transports requires a separate multicast local network in the gatewaydaemon in order to communicate with gateway clients.

Subject GatingMessages do not flow into or out from a local network unless you configure subject gating. To importand export subjects with respect to local networks, configure subject gating for each local networkinterface.

However, subject gating is not sufficient for messages to flow. Clients must also express interest in asubject (by subscribing) to allow messages to flow across the network boundary.

To configure subject gating, see "Routing Daemon (rvrd): Subject Gating" in TIBCO RendezvousAdministration.

Redundancy and the Gateway—Use CasesThe following topics present two use cases for redundant gateway daemons—the first withoutmulticast clients, and the second with multicast clients. The presentation of each use case includes theconfiguration task, a narration of normal operation, and a narration of failover operation.

Redundant Gateways, No Multicast ClientsThe most straightforward use case for redundant gateway daemons is the case without any multicastclients.

38


Configuring Redundant Gateways, No Multicast Clients

In this use case, all clients connect to a daemon within a Rendezvous zone. The two zones communicatethrough a neighbor link between gateway daemons.

Gateway Configuration, Fault Tolerance, No Multicast

Procedure

Task A: Configure Routing Table Entries

1. Configure RVGD 1.A and RVGD 2.A so they each have a routing table entry.

2. Configure RVGD 1.B and RVGD 2.B so they each have a routing table entry.

Task B: Configure Gateway LANs

To configure identical values in two gateway daemons, you can copy an individual value fromthe browser administration interface of one rvgd, and paste that value into the browseradministration interface of the other rvgd.

3. Configure RVGD 1.A and RVGD 2.A identically regarding their gateway LANs (on VIP A). Eventhough these local networks are gateway LANs within separate zones, they represent the same setof gateway clients that connect to virtual IP address A.

4. Configure RVGD 1.B and RVGD 2.B identically regarding their gateway LANs (on VIP B). Eventhough these local networks are gateway LANs within separate zones, they represent the same setof gateway clients that connect to virtual IP address B.

Task C: Configure Neighbors

5. Add an active neighbor connection at RVGD 1.B, connecting to RVGD 1.A.

39


6. Add a passive neighbor connection at RVGD 1.A, permitting connection from RVGD 1.B.

7. Add an active neighbor connection at RVGD 2.A, connecting to RVGD 2.B.

8. Add a passive neighbor connection at RVGD 2.B, permitting connection from RVGD 2.A.



Task D: Configure Subject Gating

11. Configure RVGD 1.A and RVGD 2.A identically regarding subject gating with respect to theirgateway LANs (on VIP A).

12. Configure RVGD 1.B and RVGD 2.B identically regarding subject gating with respect to theirgateway LANs (on VIP B).

Normal Gateway Operation, No Multicast Clients

This diagram illustrates normal gateway operation of the use case without multicast clients; bothnetwork server hosts are available.

Gateway Operation, Fault Tolerance, No Multicast

● Virtual router VR-1.A (not shown) is in the master state. Gateway clients connect to RVD-1.A atvirtual IP address A.

Virtual router VR-2.A (not shown) is waiting in the backup state.● Virtual router VR-2.B (not shown) is in the master state. Gateway clients connect to RVD-2.B at

virtual IP address B.

Virtual router VR-1.B (not shown) is waiting in the backup state.● Gateway daemons RVGD 1.A and RVGD 2.B are in the running state, with a neighbor connection

between them. These neighbors route messages between the A and B clients groups.

40


● Gateways daemons RVGD 1.B and RVGD 2.A are in the idle state.

An idle gateway daemon does not communicate with neighbors or local networks, anddoes not forward any data. You can configure it through its browser administrationinterface, but otherwise it is effectively invisible and inert. In this respect, an idle gatewaydaemon behaves like an idle routing daemon.

(In contrast, when routing daemons—that is, instances of rvrd—are in a redundantconfiguration, they are always running—rather than waiting idle. They can communicatewith their neighbors and local networks, and they can forward data.)

Failover Behavior, No Multicast Clients

This diagram illustrates failover when network server host 2 fails (in the use case without multicastclients).

Gateway Failover, Fault Tolerance, No Multicast

● Virtual router VR-1.B (not shown) enters the master state, and clients of virtual IP address Breconnect to RVD 1.B.

● Gateway daemon RVGD 1.B transitions from the idle state to the running state, and establishes apre-configured neighbor connection to gateway daemon RVGD 1.A. This connection completes aroute from gateway clients of virtual IP address A to clients of virtual IP address B.

Redundant Gateways, Multicast ClientsIf you must integrate redundant network servers with existing Rendezvous multicast networks,consider this second use case, which includes multicast clients.

41


Configuring Redundant Gateways, Multicast Clients

A use case that includes multicast clients leads to a slightly different configuration than a case withoutmulticast clients. Multicast clients connect to daemons on a multicast network. The multicast network isa local network for two gateway daemons, one in each Rendezvous zone. The two zones communicatethrough the multicast network (not through a neighbor link).

Compare this diagram with the diagram Gateway Configuration, Fault Tolerance, No Multicast. Noticethat in this diagram the multicast LAN replaces the neighbor connection between the two zones.Replacing the neighbor connection (rather than supplementing it) is crucial to avoid creating a routingloop, which would be illegal.

Gateway Configuration, Fault Tolerance, Multicast

Procedure

Task A: Configuring Routing Table Entries

The steps in this subtask are identical to the use case without multicast clients.

1. Configure RVGD 1.A and RVGD 2.A so they each have a routing table entry.

2. Configure RVGD 1.B and RVGD 2.B so they each have a routing table entry.

Task B: Configuring Gateway LANs

To configure identical values in two gateway daemons, copy an individual value from thebrowser administration interface of one rvgd, and paste that value into the browseradministration interface of the other rvgd.

3. Configure RVGD 1.A and RVGD 2.A identically regarding their gateway LANs (on VIP A). Eventhough these local networks are gateway LANs within separate zones, they represent the same setof gateway clients that connect to virtual IP address A.

42


4. Configure RVGD 1.B and RVGD 2.B identically regarding their gateway LANs (on VIP B). Eventhough these local networks are gateway LANs within separate zones, they represent the same setof gateway clients that connect to virtual IP address B.

Task C: Configuring Neighbors

Notice that these steps configure only two neighbors, rather than three. Each of the two connections iswithin a zone, rather than zone to zone.

5. Add an active neighbor connection at RVGD 1.B, connecting to RVGD 1.A.

6. Add a passive neighbor connection at RVGD 1.A, permitting connection from RVGD 1.B.



Task D: Configuring Multicast LANs

To avoid a routing loop, configure only one local (multicast) network in each zone.

9. Configure RVGD 1.A with a local network on the multicast LAN through the unique IP address ofzone 1 (UIP 1).

10. Configure RVGD 2.B with a local network on the multicast LAN through the unique IP address ofzone 2 (UIP 2).

Task E: Configuring Subject Gating

11. Configure RVGD 1.A and RVGD 2.A identically regarding subject gating with respect to theirgateway LANs (on VIP A).

12. Configure RVGD 1.B and RVGD 2.B identically regarding subject gating with respect to theirgateway LANs (on VIP B).

13. Configure RVGD 1.A and RVGD 2.B identically regarding subject gating with respect to themulticast LAN (on UIP 1 or UIP 2).

43


Normal Gateway Operation, Multicast Clients

This diagram illustrates normal gateway operation of the use case with multicast clients; both networkserver hosts are available.

Gateway Operation, Fault Tolerance, Multicast

● Virtual router VR-1.A (not shown) is in the master state. Gateway clients connect to RVD-1.A atvirtual IP address A.

Virtual router VR-2.A (not shown) is waiting in the backup state.● Virtual router VR-2.B (not shown) is in the master state. Gateway clients connect to RVD-2.B at

virtual IP address B.

Virtual router VR-1.B (not shown) is waiting in the backup state.● Gateway daemons RVGD 1.A and RVGD 2.B are in the running state, and router messages between

their respective gateway LANs and the multicast LAN. The multicast LAN links the two rvgdinstances.

● Gateways daemons RVGD 1.B and RVGD 2.A are in the idle state.

An idle gateway daemon does not communicate with neighbors or local networks, anddoes not forward any data. You can configure it through its browser administrationinterface, but otherwise it is effectively invisible and inert. In this respect, an idle gatewaydaemon behaves like an idle routing daemon.

(In contrast, when routing daemons, instances of rvrd, are in a redundant configuration,they are always running—rather than waiting idle. They can communicate with theirneighbors and local networks, and they can forward data.)

44


Failover Behavior, Multicast Clients

This diagram illustrates failover when network server host 2 fails (in the use case with multicast clients).

Gateway Failover, Fault Tolerance, Multicast

● Virtual router VR-1.B (not shown) enters the master state, and clients of virtual IP address Breconnect to RVD 1.B.

● Gateway daemon RVGD 1.B transitions from idle to running state, and establishes a pre-configuredneighbor connection to gateway daemon RVGD 1.A. This connection completes a route fromgateway clients of virtual IP address A to clients of virtual IP address B, as well as a route fromgateway clients of virtual IP address B to the transports on the multicast LAN.

45


Adapter: Communication between Rendezvous and FTLApplications

You can arrange communication between TIBCO Rendezvous applications and TIBCO FTLapplications using a daemon with an adapter module.

For brevity, adapter documentation uses the term FTL application to refer to any customer program thatuses TIBCO FTL API calls. Similarly, the term Rendezvous application refers to any customer programthat uses TIBCO Rendezvous API calls. Similar terms refer to other items within customer programs orwithin the adapter module, such as: FTL message, FTL field, FTL format, Rendezvous subject, Rendezvousnetwork, FTL message, FTL field, FTL side, and Rendezvous side.

An understanding of TIBCO FTL messaging technology is helpful when reading this material.

Adapter OverviewThe adapter converts messages so TIBCO FTL programs can communicate with existing TIBCORendezvous programs. The adapter translates messages in both directions.

To understand the adapter, consider it from three perspectives:

● FTL application perspective● Rendezvous application perspective● Adapter perspective

Adapter

FTL Application Perspective

From the perspective of FTL applications (right side of the diagram above), the adapter behaves likeany other FTL application. It can publish messages and subscribe to messages. It contacts the realmserver to get formats and transports, just as any other application would. It communicates with otherFTL applications over FTL transports, as defined in the realm.

Rendezvous Application Perspective

From the perspective of Rendezvous applications (left side of the diagram above), the adapter appearslike a TIBCO Rendezvous daemon. Indeed, it is a daemon, even though it includes an additionalmodule that provides adapter functionality. This enhanced daemon replaces an rvd service within thezone.

Rendezvous applications connect to the enhanced daemon as they would connect to any daemon. Thedaemon delivers inbound messages to applications, and accepts outbound messages from applications,as any daemon would. Furthermore, all the clients that connect to the same daemon can exchangeRendezvous messages, which is the expected behavior for clients of any daemon.

46


Adapter Perspsective

Within the adapter module, messages flow in two directions between its Rendezvous side and its FTLside. FTL messages and Rendezvous messages are very different, so the adapter translates thesemessages according to its configuration.

The central portion of the adapter in the diagram above shows the two translators, one for eachdirection.

Adapter OperationThe adapter has three operating parts: the adapter start phase, the FTL side, and the Rendezvous side.

Adapter Start PhaseWhen the adapter starts, it does these preparatory steps.

1. The adapter reads the configuration file.

2. The adapter contacts the realm server to get the realm definition.

3. The adapter validates its configuration.

If the adapter configuration is incompatible with the realm in any way, or violates other constraints,then the daemon disables its adapter functionality. Nonetheless, standard rvd daemon functionalityis available.

4. If the start phase succeeds in reaching this point, the adapter starts both its FTL side and itsRendezvous side.

Adapter FTL SideThe adapter's FTL side translates FTL messages into Rendezvous messages and transmits them toRendezvous clients.

The adapter's FTL side creates one subscriber for each endpoint in the adapter configuration. Thesesubscribers do not include content matchers, so they receive all messages on the endpoint.

Each time a subscriber receives a message with a format specified in one of the configuration’s fromFTLtags, the adapter attempts to translate it to a Rendezvous message. The fromFTL tag guides thetranslation. The adapter first finds the set of FTL fields that translate into the Rendezvous subject orinbox name. Then the adapter translates each remaining field:

● The FTL field name becomes a Rendezvous field name.● Every FTL field data type either maps unambiguously to a Rendezvous field data type, or raises an

error. For details, see Adapter Data Type Mapping.● The FTL field value translates to the Rendezvous field value of the appropriate data type.

After translating all the fields, the adapter transmits the translated Rendezvous message to all its clientsthat have expressed interest in the translated Rendezvous subject.

Adapter Rendezvous SideThe adapter's Rendezvous side translates Rendezvous messages into FTL messages, and transmitsthem to FTL clients.

The adapter's Rendezvous side begins by listening for connections from Rendezvous clients. Clientsconnect to the adapter as they would connect to a TIBCO Rendezvous daemon.

The adapter processes each message that its Rendezvous clients send.

Each time a Rendezvous message matches the subject specification in one of the configuration’s fromRVtags, the adapter attempts to translate it to an FTL message. The fromRV tag guides the translation.

47


1. The adapter translates and stores the Rendezvous subject.

● If the Rendezvous subject is a multicast subject name, the adapter stores its elements in FTLfields.

● If the Rendezvous subject is an inbox name, the adapter maps it to an FTL inbox and stores theFTL inbox in an FTL field.

2. Then the adapter attempts to fill each of the remaining fields of the FTL format with values from theRendezvous message.

The adapter attempts to get a Rendezvous field with the same name as the FTL field.

● If the Rendezvous field type maps to an FTL field data type (see Adapter Data Type Mapping),then the adapter translates the Rendezvous field value to an FTL field value of the appropriatedata type.

● If the Rendezvous field type does not map to an FTL field data type (see Adapter Data TypeMapping), then the adapter either discards the entire message, or skips the field, depending onthe discardMessages attribute of the fromRV tag.

3. After translating all the FTL fields, the adapter publishes the translated FTL message on the relevantFTL endpoints.

Rendezvous Unnamed Fields

Rendezvous messages support unnamed fields, accessed only by index or field identifier. In contrast,FTL messages do not support unnamed fields.

The adapter does not translate unnamed fields. When translating a Rendezvous message, the adapterignores unnamed fields.

Configuring the AdapterThe adapter configuration file guides the adapter as it translates and forwards messages betweenRendezvous applications and FTL applications.

TIBCO FTL has an adapter component that is similar but not identical. If you have already configuredadapter functionality within TIBCO FTL, it is straightforward to convert that configuration for TIBCORendezvous Network Server. The file format changes from XML to JSON. The names of configurationtags are different, though analogous. Some tags that apply to adapter in TIBCO FTL do not apply inTIBCO Rendezvous Network Adapter.

Procedure

1. Create an adapter configuration file in JSON format.This file determines the message translation and forwarding behavior of the adapter. For syntaxand semantics, see Adapter Configuration Reference.

2. Store that file on the adapter host.For fault tolerance, store it on each host of the redundant pair.

3. Open the appropriate configuration file for editing.

Option Description

Creating a new zone. Edit your private copy of the configuration file trns.conf.

48


Option Description

Modifying an existing zone. Edit the zone reference configuration file /var/tibco/stores/trns.conf in place. It is good practice to make a backup copyfirst.

Both documented and undocumented parameters can appear inthe reference configuration file. Do not edit undocumentedconfiguration parameters.

4. Set the VIP's adapter configuration parameter to the location of the adapter configuration file.This parameter value cues the daemon service script to start a daemon with an adapter moduleinstead of an ordinary rvd.If the zone administration utility cannot locate the adapter configuration file, the zone creation orzone update operation fails.For fault tolerance, do this step on each zone of the redundant pair.

5. Apply the new parameter values.

Option Description

Creating a new zone. Complete the task Creating a Rendezvous Zone.

Modifying an existing zone. Complete the task Updating a Zone to a New Software Release.

For more detail, see also Zone Administration Utility Reference.

Result

When the zone boots, the daemon service script starts a daemon with an adapter module. The adapterreads its configuration file to guide its operation. If the configuration contains errors, the service doesnot function as an adapter, but instead reverts to ordinary daemon (rvd) functionality.

Adapter Configuration ReferenceThe adapter configuration file governs message translation.

General Syntax

The adapter configuration file is a JSON document. For information about JSON syntax andterminology, see http://www.json.org. Use commas to separate elements of arrays, or elements ofobjects.

49


http://www.json.org

Top Level

Name Description

realm Begin the adapter configuration. Top level object. Exactly one.

Required properties:

● applicationName

● url

● services

Optional properties:

● secondaryURL

● username

● password

● fromFTL

applicationName Required. Exactly one. String.

The FTL side of the adapter uses this name to get its tailored realmfrom the realm server. The realm must define an application with thisname.

Contained in: realm.

url Required. Exactly one. String.

The adapter contacts the realm server at this location. A realm servermust be listening at the location.


secondaryURL Optional. At most one. String.

If the regular realm server fails, the adapter can failover to the backuprealm server at this location.


JAAS Authentication

Name Description

username Optional. Required for JAAS authentication. At most one. String.

When present, the adapter authenticates itself to the realm server usingthis user name.


50


Name Description

password Optional. Required for JAAS authentication. At most one. String.

When present, the adapter authenticates itself to the realm server usingthis password.To hide the password from casual observers, you can first obfuscate thepassword using the tibrealmadmin --mangle (a command line utilityin the TIBCO FTL software product).


Services

Name Description

services Required. Exactly one array, with at least one element.

Configure Rendezvous services, and configure adapter behavior withrespect to each service.

Each element denotes a Rendezvous service.

Required properties of each array element:

● port

● endpoints

● fromRV


port Required. Exactly one. String.

The adapter maps this Rendezvous service (that is, a port number) toone or more FTL endpoints, translating messages in both directions.

Contained in: elements of the services array.

endpoints Required. Exactly one array, with at least one element. Elements arestrings. The strings must be unique.

The adapter maps these FTL endpoints to the Rendezvous service (seethe enclosing services element), translating messages in bothdirections.

When this array contains several endpoint elements, the adaptertranslates each Rendezvous message from the Rendezvous service onlyonce, and forwards the translation to all of the FTL endpoints.


51


Translating Rendezvous Messages to FTL Messages

Name Description

fromRV Optional. An array with at least one element.

Configure a translation from Rendezvous messages to FTL messages.

Required properties:

● formatName

● subjectName

● parseSubject


● discardMessages

● replyFieldName


subjectName Required. Exactly one. String.

The adapter selects a subset of Rendezvous messages to translate fromthe enclosing service element. That is, the adapter translates onlymessages with subjects that match this specification. The specificationmay contain Rendezvous wildcard elements.

For important details, see Rendezvous Subjects.

Contained in: fromRV elements.

parseSubject Required. Exactly one array with at least one element.

This array instructs the adapter as it parses Rendezvous messagesubjects into fields in the target FTL format.Each array element has the formfield_name:n

In each element, field_name designates a field in the target FTL format,and n represents a subject token position in the Rendezvous subject.The parser stores the nth subject token as the value of the fieldfield_name.

The data type of all of the FTL fields must be TIB_FIELD_TYPE_STRING.

If the Rendezvous subject name has fewer tokens than the parserrequires, the adapter discards the message immediately.

Contained in: elements of the fromRV array.

formatName Required. Exactly one. String.

The adapter translates Rendezvous messages into this managed FTLformat.


52


Name Description

discardMessages Optional. At most one. Boolean.

This value governs adapter behavior when it cannot translate aRendezvous field into an FTL field type.

When true, the adapter discards the entire Rendezvous message anddoes not produce an FTL translation.

When false, the adapter skips the offending field and continues itsattempt to translate the rest of the message to an FTL message.

When absent, the default is false.


replyFieldName Optional. Required for request/reply interactions. At most one. String.

Specifies a field name in the FTL format. If the Rendezvous messageincludes a reply subject, the adapter maps that Rendezvous inbox nameto an FTL inbox, and stores the FTL inbox in this FTL field. Later, whenan FTL program sends a reply to that FTL inbox, the adapter translatesthe reply and forwards the translation to the original Rendezvous inboxsubject.


Translating FTL Messages to Rendezvous Messages

Name Description

fromFTL Optional. An array with at least one element.

Configure a translation from FTL messages to Rendezvous messages.

Required elements:

● formatName

● assembleSubject


● discardMessages

● replyFieldName

● expectReplyFormatName


formatName Required. Exactly one. String.

Specifies a managed FTL format. The adapter uses information in thisobject to translate all FTL messages with this format.

Contained in: elements of the fromFTL array.

53


Name Description

assembleSubject Required. Exactly one array with at least one string element.

This array instructs the adapter as it assembles designated fields of anFTL message into a Rendezvous subject name.

Each element of the array is a string designating a field name in the FTLformat.

The adapter assembles a Rendezvous subject by concatenating thevalues of the FTL fields, separating them with period (.) characters.


discardMessages Optional. At most one. Boolean.

This value governs adapter behavior when it cannot translate an FTLfield into a Rendezvous field type and also when it cannot translate aRendezvous field in a reply message into an FTL field type.

When true, the adapter discards the entire message and does notproduce a translation.

When false, the adapter skips the offending field and continues itsattempt to translate the rest of the message.

When absent, the default is false.


replyFieldName Optional. Required for request/reply interactions. At most one. String.

Specifies a field name in the FTL format. When present, the adaptermaps the inbox value of this FTL field to a Rendezvous inbox replysubject, which it stores on the Rendezvous message. Later, when aRendezvous program sends a reply to that reply subject inbox, theadapter translates the reply and forwards the translation to the originalFTL inbox.


expectReplyFormatName Optional. Required for request/reply interactions. At most one. String.

Specifies an FTL format. When present, the adapter remembers that theFTL requestor expects a reply message with this format and uses thisformat when translating the reply.


Adapter Administration: RealmThe realm definition must satisfy all of these constraints to support the FTL side of the adapter.

Communication through Transports

● The adapter must be able to communicate with the realm server.● Administrators must configure transports to establish a bus to carry messages between FTL

programs and the FTL side of the adapter.● The realm must configure appropriate communications paths for each message stream.

54


Bidirectionality

During its start phase, the adapter creates a publisher and a subscriber for each of its endpoints.Administrators must ensure that the realm supports these objects for each adapter endpoint. That is, foreach adapter endpoint, the connectors in the adapter’s application instance definition must cover atleast the send ability and the receive ability. This requirement applies even if you intend that messagesflow through the adapter in only one direction.

One-to-One Abilities

If the adapter uses an endpoint to forward one-to-one messages, then the connectors that implementthat endpoint within the adapter’s application instance definition must cover either the send inboxability, the receive inbox ability, or both, as needed.

In contrast, if the adapter does not forward one-to-one messages, then the connectors need not covereither of these abilities.

Adapter Data Type Mapping

Data Type Mapping: FTL to RendezvousThe mapping from FTL message fields to Rendezvous message fields is straightforward. Each FTL typemaps to a Rendezvous type, according to the following table. The mapping is intuitive and requires nodata conversion.

Some FTL types do not map to any Rendezvous representation. These fields raise an error (see DataType Mapping Errors).

Data Type Mapping: FTL to Rendezvous

FTL Type Rendezvous Type

TIB_FIELD_TYPE_OPAQUE TIBRVMSG_OPAQUE

TIB_FIELD_TYPE_LONG TIBRVMSG_I64

TIB_FIELD_TYPE_LONG_ARRAY TIBRVMSG_I64ARRAY

TIB_FIELD_TYPE_DOUBLE TIBRVMSG_F64

TIB_FIELD_TYPE_DOUBLE_ARRAY TIBRVMSG_F64ARRAY

TIB_FIELD_TYPE_STRING TIBRVMSG_STRING

TIB_FIELD_TYPE_STRING_ARRAY TIBRVMSG_STRINGARRAY

TIB_FIELD_TYPE_MESSAGE Error

TIB_FIELD_TYPE_MESSAGE_ARRAY Error

TIB_FIELD_TYPE_INBOX Error

TIB_FIELD_TYPE_DATETIME TIBRVMSG_DATETIME

TIB_FIELD_TYPE_DATETIME_ARRAY Error

55


Data Type Mapping: Rendezvous to FTLBecause TIBCO Rendezvous software supports a very rich set of data types, while TIBCO FTL softwaresupports a deliberately narrow set of data types, the adapter coerces several Rendezvous types into thesame FTL type.

Some Rendezvous types do not map to any FTL representation. These fields raise an error (see DataType Mapping Errors).

Data Type Mapping: Rendezvous to FTL

Rendezvous Type FTL Type

TIBRVMSG_OPAQUE TIB_FIELD_TYPE_OPAQUE

TIBRVMSG_BOOL Error

TIBRVMSG_I8

TIBRVMSG_I16

TIBRVMSG_I32

TIBRVMSG_I64

TIBRVMSG_U8

TIBRVMSG_U16

TIBRVMSG_U32

TIB_FIELD_TYPE_LONG

TIBRVMSG_U64 Error

TIBRVMSG_I8ARRAY

TIBRVMSG_I16ARRAY

TIBRVMSG_I32ARRAY

TIBRVMSG_I64ARRAY

TIBRVMSG_U8ARRAY

TIBRVMSG_U16ARRAY

TIBRVMSG_U32ARRAY

TIB_FIELD_TYPE_LONG_ARRAY

TIBRVMSG_U64ARRAY Error

TIBRVMSG_F32

TIBRVMSG_F64

TIB_FIELD_TYPE_DOUBLE

TIBRVMSG_F32ARRAY

TIBRVMSG_F64ARRAY

TIB_FIELD_TYPE_DOUBLE_ARRAY

TIBRVMSG_STRING TIB_FIELD_TYPE_STRING

TIBRVMSG_STRINGARRAY TIB_FIELD_TYPE_STRING_ARRAY

TIBRVMSG_MSG Error

TIBRVMSG_MSGARRAY Error

TIBRVMSG_DATETIME TIB_FIELD_TYPE_DATETIME

56


Rendezvous Type FTL Type

All other Rendezvous types Error

Data Type Mapping ErrorsWhen a data type mapping raises an error, the adapter responds according to the discardMessagesattribute.

This attribute can appear in the fromRV tag or the fromFTL tag.

● If the value of discardMessages is true, then the adapter discards the entire message.

● Otherwise, the adapter skips the offending field and continues translating the message.

Request Reply Interactions through the AdapterRequest/reply interactions involve complex configuration constraints. Only three situations arepossible.

Primary FTL Request, Secondary Rendezvous Reply to an InboxAn FTL program sends a request message. The adapter detects that it is a request message because itmeets all of these criteria.

● The format of the message matches the format of a fromFTL configuration tag.

● The replyField of that fromFTL tag specifies the name of an FTL field, called the reply field.

● The realm defines the format such that the reply field has type TIB_FIELD_TYPE_INBOX.

● That reply field is present in the message.● The expectReplyFormat of the fromFTL tag specifies the name of an FTL format, called the reply

format. The requestor expects a reply message in this reply format.● The realm must define the reply format.

To configure this case, ensure that the adapter configuration meets these six criteria.

The adapter arranges a mechanism through which a Rendezvous program can reply to the FTL request:

1. The adapter gets the value of the reply field, namely, the FTL inbox where the requestor awaits areply.

2. The adapter maps that FTL inbox to a Rendezvous inbox within the adapter.

3. In the Rendezvous translation of the request message, the adapter sets the reply subject to thatRendezvous inbox.

4. Later, when a Rendezvous program sends a reply to that inbox, the adapter receives it, translates itto an FTL message using the reply format, and forwards it to the FTL inbox where the requestorawaits the reply.

Secondary Rendezvous Request to an Inbox, Tertiary FTL ReplyA Rendezvous reply to an inbox could itself be a secondary request in a longer chain of point-to-pointmessages. The adapter detects this situation because the secondary message meets all of these criteria.

● The adapter receives the secondary message at an adapter inbox, so the message must be aRendezvous reply to an FTL request.

● The reply subject of the secondary Rendezvous message contains a Rendezvous inbox name, so thesender must be awaiting a tertiary reply.

57


The adapter repurposes the reply field from the primary request so an FTL program can send a tertiaryreply to the secondary Rendezvous request. The reply field is an FTL field name, specified as the value ofthe replyField of the fromFTL configuration tag, which is the same tag that governed translation ofthe primary FTL request message.

1. The adapter gets the reply subject, namely, the Rendezvous inbox name where the requestor awaitsa reply.

2. The adapter maps that Rendezvous inbox to an FTL inbox within the adapter, called the reply inbox.

3. In the FTL translation of the secondary request message, the adapter stores the reply inbox in thereply field.

4. Later, when an FTL program sends its tertiary reply to the reply inbox, the adapter receives it,translates it to a Rendezvous message, and forwards it to the reply subject. That reply subject is theRendezvous inbox where the secondary requestor awaits the tertiary reply.

Because you have already configured the adapter to translate the primary request (see Primary FTLRequest Secondary Rendezvous Reply to an Inbox), you do not need any additional configuration toforward the secondary request, nor to forward the tertiary reply.

Nonetheless, if the format of the tertiary reply differs from the format of the primary request, you mustconfigure a separate fromFTL tag to translate that format. This case has the same form as theconfiguration for the primary request.

Primary Rendezvous Request to a Subject, Secondary FTL Reply to an InboxA Rendezvous program sends a request message to a multicast subject, rather than to an inbox. Theadapter detects that it is a multicast request message because it meets all of these criteria.

● The subject of the message matches the subject attribute of a fromRV configuration tag.

● The replyField attribute of that fromRV tag specifies the name of an FTL field, called the reply field.

● The realm defines the format such that the reply field has type TIB_FIELD_TYPE_INBOX.

To configure this case, ensure that the adapter configuration meets these three criteria.

The adapter arranges a mechanism through which an FTL program can reply to the Rendezvousrequest:

1. The adapter gets the reply subject, namely, the Rendezvous inbox name where the requestor awaitsa reply.

58


2. The adapter maps that Rendezvous inbox to an FTL inbox within the adapter, called the reply inbox.

3. In the FTL translation of the request message, the adapter stores the reply inbox in the reply field.

4. Later, when an FTL program sends a reply to that reply inbox, the adapter receives it, translates it toa Rendezvous message, and forwards it to the reply subject. That reply subject is the Rendezvousinbox where the requestor awaits the reply.

Rendezvous SubjectsThe Rendezvous subjects you configure for conversion must be distinct.

The adapter validates the subject attribute of each fromRV tag, using the following rules:

● Within the scope of a service tag, the subjects of the fromRV tags must not collide with one another.

This restriction does not apply between fromRV tags that are in different service tags.

● If a literal subject is identical to a previous literal subject, then they collide (not permitted).● If a literal subject matches a previous wildcard subject, then they do not collide (permitted).● If a wildcard subject matches a previous literal subject, then they do not collide (permitted).● If a wildcard subject matches a previous wildcard subject, then they collide (not permitted).

Examples

Validating Rendezvous Subjects

Subject 1 Subject 2 Conformance

a.b a.b.c Permitted

a.b a.* Permitted

a.* a.b Permitted

a.b a.> Permitted

a.> a.b Permitted

a.b a.b Collide

a.* a.> Collide

a.> a.* Collide

a.* *.b Collide

*.b a.* Collide

Messages that Match Two Rendezvous Subjects

The above restriction against colliding subjects helps ensure that the adapter translates eachRendezvous message at most once.

The adapter forbids combinations in which two wildcard subjects collide, preventing ambiguity.

59


The adapter permits combinations in which a message might match both a literal subject and awildcard subject. In this situation, the adapter translates the message according to the fromRV tag thatspecified the literal subject.

Adapter RestrictionsAlthough the adapter is flexible, these restrictions apply.

● The adapter does not support FTL messages with dynamic formats. It can translate an FTL messageonly if it uses a pre-loaded format. It can translate a Rendezvous message only into a managed FTLformat.

● The adapter does not translate FTL messages of types TIB_BUILTIN_MSG_FMT_OPAQUE norTIB_BUILTIN_MSG_FMT_KEYED_OPAQUE. Instead, you must define a managed format with oneopaque field.

60


Commands Reference Summary

Zone Administrative Commands ReferenceAdministrators use these operating system commands to view zones, and to start or stop zones.

Some of these commands require root privileges. To acquire root privileges, a user with adminprivileges can start a root shell using the pfexec bash command.

Some common operating system commands accept a zone option, which narrows the scope of thecommand to a specific zone. For example, prstat -z zone_name reports only on processes within thezone you specify.

This table is a brief summary of zone commands. For more detail, see the operating systemdocumentation (man pages) for these commands.

Zone Commands

Task Command Privilege Required

Login to a zone zlogin zone_name

View running zones(excludes halted zones)

zoneadm list

View all installed zones zoneadm list -i

Reboot a zone(that is, halt the zone,then restart it)

zoneadm -z zone_name reboot Root

Halt a zone(that is, stop the virtualmachine)

zoneadm -z zone_name halt Root

Restart a zone(that is, start the virtualmachine)

zoneadm -z zone_name boot Root

View process statistics prstat -z zone_name

View data links dladm show-link

VRRP Commands ReferenceAdministrators use these operating system commands to view virtual routers, and to enable or disablevirtual routers.

This table is a brief summary of the most useful virtual router commands. For further details see theoperating system documentation (man pages) for these commands.

61


VRRP Commands

Task Command

View the state of avirtual router

vrrpadm show-router [-x] router_name

View the state of allvirtual routers in thezone

vrrpadm show-router [-x]

Enable a virtual router vrrpadm enable-router router_name

Disable a virtual router vrrpadm disable-router router_name

Service Administrative Commands ReferenceWhile the master control program (MCP) automatically controls the state of Rendezvous services, youcan also control those services explicitly. Administrators use these operating system commands to viewTIBCO Rendezvous Network Server services and to enable or disable services.

Some of these commands require root privileges. To acquire root privileges, a user with adminprivileges can start a root shell using the pfexec bash command.

This table is a brief summary of the most useful service administration commands. For further detailssee the operating system documentation (man pages) for these commands.

Operating System Commands

Task Command Privilege Required

View the states of allTIBCO services

svcs *tibco*

Enable a service svcadm enable service_name Root

Disable a service svcadm disable service_name Root

Start a root shell pfexec bash Admin

62


TIBCO Rendezvous Network Server Administration

Documents

Transcript of TIBCO Rendezvous Network Server Administration