RTI Routing Service

User’s Manual

Version 5.0

Contents

1	Welcome to RTI Routing Service
	1.1	Available Documentation .........................................................................................................................		1-3
2	Configuring Routing Service
	2.1	Terms to Know ...........................................................................................................................................		2-1
	2.2	How to Load the XML Configuration ....................................................................................................		2-2
	2.3	XML Syntax and Validation .....................................................................................................................		2-3
	2.4	XML Tags for Configuring Routing Service ..........................................................................................		2-5
		2.4.1	Routing Service............................................................................................................................	2-6
		2.4.2	Domain Route ..............................................................................................................................	2-9
		2.4.3	Administration...........................................................................................................................	2-13
		2.4.4	Monitoring..................................................................................................................................	2-15
		2.4.5	Session.........................................................................................................................................	2-20
		2.4.6	Routes..........................................................................................................................................	2-22
		2.4.7	Auto Routes................................................................................................................................	2-32
		2.4.8	Adapters .....................................................................................................................................	2-37
	2.5	Enabling and Disabling Routing Service Entities ...............................................................................		2-37
	2.6	Enabling RTI Distributed Logger in Routing Service.........................................................................		2-38
	2.7	Support for Extensible Types .................................................................................................................		2-39
		2.7.1	Example ......................................................................................................................................	2-40
3	Running Routing Service
	3.1	Starting Routing Service ...........................................................................................................................		3-1
	3.2	Stopping Routing Service .........................................................................................................................		3-1
4	Transforming Data with Routing Service
	4.1	Transformation Usage and Configuration .............................................................................................		4-1
	4.2	Transformations Distributed with Routing Service..............................................................................		4-3
	4.3	Creating New Transformations ...............................................................................................................		4-4
		4.3.1	Transformation Plugin API........................................................................................................	4-5
5	Administering Routing Service from a Remote Location
	5.1	Enabling Remote Administration ...........................................................................................................		5-1

iii

	5.2 Remote Commands ...................................................................................................................................			5-2
		5.2.1	add_peer .......................................................................................................................................	5-3
		5.2.2	create .............................................................................................................................................	5-3
		5.2.3	delete .............................................................................................................................................	5-4
		5.2.4	disable ...........................................................................................................................................	5-4
		5.2.5	enable ............................................................................................................................................	5-4
		5.2.6	get ..................................................................................................................................................	5-5
		5.2.7	load ................................................................................................................................................	5-5
		5.2.8	pause .............................................................................................................................................	5-5
		5.2.9	resume...........................................................................................................................................	5-5
		5.2.10	save ................................................................................................................................................	5-5
		5.2.11	unload ...........................................................................................................................................	5-5
		5.2.12	update ...........................................................................................................................................	5-6
	5.3 Accessing Routing Service from a Connext Application.....................................................................			5-8
6	Monitoring Routing Service from a Remote Location
	6.1	Enabling Remote Monitoring...................................................................................................................		6-2
	6.2	Monitoring Configuration Data ..............................................................................................................		6-2
		6.2.1	Configuration Data for Routing Service ..................................................................................	6-2
		6.2.2	Configuration Data for a Domain Route..................................................................................	6-4
		6.2.3	Configuration Data for a Session ..............................................................................................	6-5
		6.2.4	Configuration Data for a Route.................................................................................................	6-6
		6.2.5	Configuration Data for an Auto Route....................................................................................	6-11
	6.3	Monitoring Status ....................................................................................................................................		6-15
		6.3.1	How the Statistics are Generated ............................................................................................	6-16
		6.3.2	Status Information for the Routing Service ...........................................................................	6-17
		6.3.3	Domain Route Status ................................................................................................................	6-19
		6.3.4	Status Information for a Session .............................................................................................	6-20
		6.3.5	Status Information for a Route ................................................................................................	6-21
		6.3.6	Status Information for an Auto Route ...................................................................................	6-22
7	Traversing Wide Area Networks
	7.1	TCP Communication Scenarios...............................................................................................................		7-2
		7.1.1	Communication Within a Single LAN .....................................................................................	7-2
		7.1.2	Symmetric Communication Across NATs ...............................................................................	7-2
		7.1.3	Asymmetric Communication Across NATs ............................................................................	7-3
		7.1.4	Secure Communication ..............................................................................................................	7-3
	7.2 Configuring the TCP Transport...............................................................................................................			7-4
		7.2.1	TCP Transport Initial Peers ........................................................................................................	7-4
		7.2.2	Setting Up the TCP Transport Properties with the PropertyQoSPolicy..............................	7-5
		7.2.3	TCP/TLS Transport Properties .................................................................................................	7-7
8	Extending Routing Service with Adapters
	8.1 Adapter Usage and Configuration..........................................................................................................			8-1
	8.2 Adapter API And Entity Model ..............................................................................................................			8-3
		8.2.1	Entity Creation.............................................................................................................................	8-8
		8.2.2	Stream Discovery.........................................................................................................................	8-9
		8.2.3	Reading Data..............................................................................................................................	8-10

iv

8.3 Creating New Adapters..........................................................................................................................		8-10
8.3.1	Adapter SDK Components ......................................................................................................	8-10
8.3.2	C Adapter API ............................................................................................................................	8-11
8.3.3 My First C Adapter ...................................................................................................................		8-13
8.3.4	Debugging C Adapters.............................................................................................................	8-33
8.3.5	Java Adapter API.......................................................................................................................	8-35
8.3.6 My First Java Adapter...............................................................................................................		8-37
8.3.7	Debugging Java Adapters ........................................................................................................	8-52
8.3.8	Testing an Adapter ....................................................................................................................	8-55

v

Chapter 1 Welcome to RTI Routing Service

Welcome to RTI® Routing Service, an out- of-the-box solution for integrating disparate and geographically dispersed systems. It scales RTI Connext™ (formerly RTI Data Distribution Service) applications across domains, LANs and WANs, including firewall and NAT traversal. Routing Service also supports Connext-to-Connext bridging by allowing you to make transformations in the data along the way. This allows unmodified Connext applications to communicate even if they were developed using incompatible interface definitions. This is often the case when integrating new and legacy applications or independently developed systems. Using RTI Routing Service Adapter SDK, you can extend Routing Service to interface with non-

Connext systems using off-the-shelf or custom developed adapters, including to third-party JMS implementations and legacy code written to the network socket API.

Traditionally, Connext applications can only communicate with applications in the same domain. With Routing Service, you can send and receive data across domains. You can even transform and filter the data along the way! Not only can you change the actual data values, you can change the data’s type. So the sending and receiving applications don’t even need to use the same data structure. You can also control which data is sent by using allow and deny lists.

Simply set up Routing Service to pass data from one domain to another and specify any desired data filtering and transformations. No changes are required in the Connext applications.

Key benefits of Routing Service:

❏It can significantly reduce the time and effort spent integrating and scaling Connext applications across Wide Area Networks and Systems-of-Systems.

Many systems today already rely on Connext to distribute their information across a Local Area Network (LAN). However, more and more of these systems are being integrated in Wide Area Networks (WANs). With Routing Service, you can scale Connext real-time publish/subscribe data-distribution beyond the current local networks and

1-1

make it available throughout a WAN—without making any changes to existing Connext applications. You can take an existing, even deployed system and integrate it with new applications or other existing systems without changing those existing systems.

❏With Routing Service, you can build modular systems out of existing systems. Data can be contained in private domains within subsystems and you can designate that only certain “global topics” can be seen across domains. The same mechanism controls the scope of discovery. Both application-level and discovery traffic can be scoped, facilitating scalable designs.

❏Routing Service provides secure deployment across multiple sites. You can partition networks and protect them with firewalls and NATS and precisely control the flow of data between the network segments.

❏It allows you to manage the evolution of your data model at the subsystem level. You can use Routing Service to transform data on the fly, changing topic names, type definitions, QoS, etc., seamlessly bridging different generations of Connext topic definitions.

❏Routing Service provides features for development, integration and testing. Multiple sites can each locally test and integrate their core application, expose selected topics of data, and accept data from remote sites to test integration connectivity, topic compatibility and specific use-cases.

❏It connects remotely to live, deployed systems so you can perform live data analytics, fault condition analysis, and data verification.

❏RTI Routing Service Adapter SDK allows you to quickly build and deploy bridges to integrate Connext and non-Connext systems. This can be done in a fraction of the time required to develop completely custom solutions. Bridges automatically inherit advanced Connext capabilities, including automatic discovery of applications; data transformation and filtering; data lifecycle management and support across operating systems; programming languages and network transports.

1-2

RTI Routing Service Adapter SDK offers an out-of-the-box solution for interfacing with third-party protocols and technology. It includes prebuilt adapters that can be used out-of-the-box to interface with third- party Java Message Service (JMS) providers or legacy code written to the network socket API. Adapters include source code so they can be easily modified to meet application- specific requirements or serve as a template for quick creation of new custom adapters.

Quickly build and deploy bridges between natively incompatible protocols and technologies using Connext

1.1Available Documentation

Routing Service documentation includes:

❏Getting Started Guide (RTI_Routing_Service_GettingStarted.pdf)—Highlights the benefits of Routing Service. It provides installation and startup instructions, and walks you through several examples so you can quickly see the benefits of using Routing Service.

❏Release Notes (RTI_Routing_Service_ReleaseNotes.pdf)—Describes system requirements and compatibility, as well as any version-specific changes and known issues.

❏User’s Manual (RTI_Routing_Service_UsersManual.pdf)—Describes how to configure Routing Service and use it remotely.

If the optional RTI Routing Service Adapter SDK is installed, you will also have the following documents:

❏RTI Routing Service Adapter SDK Installation Guide

(RTI_Routing_Service_AdapterSDK_InstallationGuide.pdf)—Describes installation instructions for RTI Routing Service Adapter SDK.

1-3

❏RTI Routing Service Adapter SDK Release Notes

(RTI_Routing_Service_AdapterSDK_ReleaseNotes.pdf)—Describes system requirements and compatibility, as well as any version-specific changes and known issues for RTI Routing Service Adapter SDK.

1-4

Chapter 2 Configuring Routing Service

This document describes how to configure Routing Service. To see installation instructions, or to walk through some simple examples, please see the Getting Started Guide.

When you start Routing Service, you can specify a configuration file in XML format (it is not required). In that file, you can set properties that control the behavior of the service. This chapter describes how to write a configuration file.

This chapter describes:

❏Terms to Know (Section 2.1)

❏How to Load the XML Configuration (Section 2.2)

❏XML Syntax and Validation (Section 2.3)

❏XML Tags for Configuring Routing Service (Section 2.4)

❏Enabling and Disabling Routing Service Entities (Section 2.5)

❏Enabling RTI Distributed Logger in Routing Service (Section 2.6)

❏Support for Extensible Types (Section 2.7)

2.1Terms to Know

Before learning how to configure Routing Service, you should become familiar with a few key terms and concepts.

❏A routing service entity refers to an execution of Routing Service.

❏A domain route defines a two-way mapping between two data domains. For example, a domain route could define a mapping between two different domains or between a Connext domain and a JMS provider's network.

❏A session defines a single-threaded context for routes. Data cannot be read and written from two routes in the session concurrently.

❏A route defines a one-way mapping between an “input” stream in one domain and an “output” stream in the other domain. For example, in a route between Connext and JMS, the input stream will be a Connext topic and the output stream will be a JMS topic or queue.

❏An auto route defines a set of potential routes that can be instantiated based on deny/ allow filters on the stream name and registered type name.

2-1

❏A transformation is a pluggable component that changes data from the “input” stream A to data in the “output” stream B.

❏An adapter is a pluggable component that allows Routing Service to consume and produce data for different data domains. By default, Routing Service is distributed with a built-in Connext adapter.

2.2How to Load the XML Configuration

Routing Service loads its XML configuration from multiple locations. This section presents the various approaches, listed in load order.

The first three locations only contain QoS Profiles and are inherited from Connext (see Chapter

15in the RTI Core Libraries and Utilities User's Manual).1

❏$NDDSHOME/resource/qos_profiles_5.0.x2/xml/NDDS_QOS_PROFILES.xml

This file contains the Connext default QoS values; it is loaded automatically if it exists.

(First to be loaded.)

❏File in NDDS_QOS_PROFILES

The files (or XML strings) separated by semicolons referenced in this environment vari- able are loaded automatically.

❏<working directory>/USER_QOS_PROFILES.xml

This file is loaded automatically if it exists.

The next locations are specific to Routing Service.

❏<Routing Service executable location>/../../resource/xml/ RTI_ROUTING_SERVICE.xml

This file contains the default Routing Service configuration; it is loaded if it exists. RTI_ROUTING_SERVICE.xml defines a service that automatically routes all types and topics between domains 0 and 1.

❏<working directory>/USER_ROUTING_SERVICE.xml

This file is loaded automatically if it exists.

❏File specified using the command line parameter -cfgFile

The command-line option -cfgFile (see Table 3.1 on page 3-2) can be used to specify a configuration file.

❏File specified using the remote command ‘load’

The load command (see Section 5.2.7) allows loading an XML file remotely. The file loaded using this command replaces to the file loaded using the -cfgFile command-line option. (Last to be loaded.)

You may use a combination of the above approaches.

Figure 2.1 shows an example configuration file. You will learn the meaning of each line as you read the rest of this chapter.

1.See <Connext installation directory>/ndds.<version>/doc/pdf/RTI_CoreLibrariesAndUtilities_UsersManual.pdf.

2.x stands for the version number of the current release.

2-2

Figure 2.1 Example XML Configuration File

<?xml version="1.0"?> <dds>

<routing_service name="TopicBridgeExample" group_name="MyGroup"> <domain_route name="DomainRoute">

<participant_1> <domain_id>0</domain_id>

</participant_1>

<participant_2> <domain_id>1</domain_id>

</participant_2>

<session name="Session">

<topic_route name="SquaresToCircles"> <input participant="1">

<registered_type_name>ShapeType</registered_type_name> <topic_name>Square</topic_name>

</input>

<output> <registered_type_name>ShapeType</registered_type_name> <topic_name>Circle</topic_name>

</output> </topic_route>

</session> </domain_route>

</routing_service> </dds>

This file configures a simple bridge from Connext domain 0 to Connext domain 1 and changes the data’s topic from Square to Circle. Both topics use the same data type (ShapeType). You will find this example in <Routing Service installation directory>/example/shapes/topic_bridge.xml. Additional examples are in the same directory.

2.3XML Syntax and Validation

The XML configuration file must follow these syntax rules:

❏The syntax is XML; the character encoding is UTF-8.

❏Opening tags are enclosed in <>; closing tags are enclosed in </>.

❏A tag value is a UTF-8 encoded string. Legal values are alphanumeric characters. Routing Service’s parser will remove all leading and trailing spaces1 from the string before it is processed.

For example, " <tag> value </tag>" is the same as "<tag>value</tag>".

❏All values are case-sensitive unless otherwise stated.

❏Comments are enclosed as follows: <!-- comment -->.

❏The root tag of the configuration file must be <dds> and end with </dds>.

1.Leading and trailing spaces in enumeration fields will not be considered valid if you use the distributed XSD doc- ument to do validation at run-time with a code editor.

2-3

Routing Service provides DTD and XSD files that describe the format of the XML content. We recommend including a reference to one of these documents in the XML file that contains the routine service’s configuration—this provides helpful features in code editors such as Visual Studio and Eclipse, including validation and auto-completion while you are editing the XML file.

The DTD and XSD definitions of the XML elements are in <Routing Service installation directory>/resource/schema/rti_routing_service.dtd and <Routing Service installation directory>/resource/schema/rti_routing_service.xsd, respectively.

To include a reference to the XSD document in your XML file, use the attribute xsi:noNamespaceSchemaLocation in the <dds> tag. For example:

<?xml version="1.0" encoding="UTF-8"?>

<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation=

"<Routing Service install directory>/resource/schema/rti_routing_service.xsd">

...

</dds>

To include a reference to the DTD document in your XML file, use the <!DOCTYPE> tag.

For example:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE dds SYSTEM "<Routing Service install directory> /resource/schema/rti_routing_service.dtd">

<dds>

...

</dds>

We recommend including a reference to the XSD file in the XML documents; this provides stricter validation and better auto-completion than the corresponding DTD file.

2-4

2.4XML Tags for Configuring Routing Service

This section describes the XML tags you can use in a Routing Service configuration file. The following diagram and Table 2.1 describe the top-level tags allowed within the root <dds> tag.

See RTI Core Libraries and Utilities User’s Manual (Ch. 15) (see note below)

Section 2.4.6.2

Section 2.4.6.5

Section 2.4.8

Section 2.4.1

Note: The RTI Core Libraries and Utilities User’s Manual is located in <Connext installation directory>/ ndds.<version>/doc/pdf/RTI_CoreLibrariesAndUtilities_UsersManual.pdf.

Table 2.1 Top-level Tags in the Configuration File

			Number
	Tags within <dds>	Description	of Tags
			Allowed
		Specifies a library of adapter plugins.
	<adapter_library>	See Adapters (Section 2.4.8) and Chapter 8: Extending Routing	0 or more
		Service with Adapters.
		Specifies a QoS library and profiles.
	<qos_library>	The contents of this tag are specified in the same manner as for a	0 or more
		Connext QoS profile file—see Chapter 15 in the RTI Core Libraries
		and Utilities User’s Manual.1
	<routing_service>	Specifies a Routing Service configuration. See Routing Service	1 or more
		(Section 2.4.1).	(required)

2-5

Table 2.1 Top-level Tags in the Configuration File

			Number
	Tags within <dds>	Description	of Tags
			Allowed
		Specifies a library of transformation plugins.
	<transformation_library>	See Data Transformation (Section 2.4.6.5) and Chapter 4:	0 or more
		Transforming Data with Routing Service.
	<types>	Defines types that can be used by the routing service.	0 or 1
		See Defining Types in the Configuration File (Section 2.4.6.2).

1.See <Connext installation directory>/ndds.<version>/doc/pdf/RTI_CoreLibrariesAndUtilities_UsersManual.pdf.

2.4.1Routing Service

A configuration file must have at least one <routing_service> tag; this tag is used to configure an execution of Routing Service. A configuration file may contain multiple <routing_service> tags.

When you start Routing Service, you can specify which <routing_service> tag to use to configure the service using the -cfgName command-line parameter.

For example:

<dds>

<routing_service name="Router1" group_name=”Group1”>

...

</routing_service>

<routing_service name="Router2" group_name=”Group1”>

...

</routing_service>

</dds>

Starting Routing Service with the following command will use the <routing_service> tag with the name Router1:

rtiroutingservice -cfgFile example.xml -cfgName Router1

Because a configuration file may contain multiple <routing_service> tags, one file can be used to configure multiple Routing Service executions.

A routing service may belong to a group of several routing services identified by a common group_name. This common name can be used to implement a specific policy when the communication happens between routing services of the same group.

2-6

For example, in the built-in Connext adapter, a participant will ignore other participants in the same group, as a way to avoid circular communication.

Section 2.4.3

Section 2.4.4

Section 2.4.4

Section 2.4.2

If the <routing_service> tag does not have a group_name attribute, Routing Service will use the

	following	name:	RTI_RoutingService_<Host	Name>_<Process	ID>,	such	as
	RTI_RoutingService_myhost_20024.
	Table 2.2	describes	the tags allowed within a <routing_service> tag. Notice that the
	<domain_route> tag is required.
Table 2.2 Routing Service Tags
	Tags within					Number
			Description			of Tags
	<routing_service>
						Allowed
			Enables and configures remote administration. See Administration
	<administration>		(Section 2.4.3) and Chapter 5: Administering Routing Service from a			0 or 1
			Remote Location.
			Contains a <documentation> tag that can be used to provide a routing
	<annotation>		service description. This description will show up when you run			0 or 1
			Routing Service without the -cfgName command-line option.
	<domain_route>		Defines a mapping between two data domains. See Section 2.4.2.			1 or	more
						(required)
	<entity_monitoring>		Enables and configures remote monitoring for the routing_service			0 or 1
			entity.

2-7

Table 2.2 Routing Service Tags

	Tags within		Number
		Description	of Tags
	<routing_service>
			Allowed

	Configures the Java JVM used to load and run Java adapters such as
	the JMS Adapter. For example:
	<jvm>
	<class_path>
	<element>SocketAdapter.jar</element>
	</class_path>
	<options>
	<element>-Xms32m</element>
	<element>-Xmx128m</element>
<jvm>	</options>	0 or 1
	</jvm>
	The class path for the Java adapters can be set using either the
	<class_path> tag or by setting the CLASSPATH environment variable.
	Routing Service will always add <Routing Service executable loca-
	tion>/../../class/rtiroutingservicesdk.jar and <Routing Service execut-
	able location>/../../class/dds.jar at the end of the user defined class
	path.
	You can use the <options> tag to specify options for the JVM, such as
	the initial and maximum Java heap sizes.
	Enables and configures general remote monitoring. General
<monitoring>	monitoring settings are applicable to all the Routing Service entities	0 or 1
	unless they are explicitly overridden. See Monitoring (Section 2.4.4).

2-8

2.4.2Domain Route

A domain route defines a mapping between two data domains. Data available in either of these data domains can be routed to the other one. For example, a domain route could define a mapping between two different Connext domains or between a Connext domain and a JMS provider's network. How this data is actually read and written is defined in specific routes.

A domain route creates two connections, known as connection_1 and connection_2. Each connection belongs to one of the two data domains.

For example:

<dds>

<routing_service name="Router1" group_name="Group1">

<domain_route name="DomainRoute1"> <connection_1 plugin_name=”...”>

. . .

</connection_1>

<connection_2 plugin_name=”...”>

...

</connection_2>

<session name="Session">

...

</session> </domain_route>

...

</routing_service> </dds>

The connection tags require the specification of the attribute plugin_name, which will be used to associate a connection with an adapter plugin defined within <adapter_library> (see Section 2.1).

2-9

For Connext domains, the connections are specified using the tags participant_1 and participant_2. Each tag has one associated DomainParticipant.

The following example routes information between two Connext domains.

<dds>

<routing_service name="Router1" group_name="Group1">

<domain_route name="DomainRoute1"> <participant_1>

<domain_id>54</domain_id>

...

</participant_1>

<participant_2> <domain_id>55</domain_id>

...

</participant_2>

<session name="Session">

...

</session> </domain_route>

...

</routing_service> </dds>

Configurations mixing connections and participants are allowed to provide communication between Connext domains and other data domains.

The following example routes information between a JMS provider network and a Connext domain.

<dds>

<routing_service name="Router1" group_name="Group1"> <domain_route name="DomainRoute1">

<connection_1 plugin_name=”adapter_library::jms”>

...

</connection_1>

<participant_2> <domain_id>55</domain_id>

...

</participant_2>

<session name="Session">

...

</session> </domain_route>

...

</routing_service> </dds>

2-10

Table 2.3 lists the tags allowed within a <domain_route> tag. Notice that most of these tags are required.

Table 2.4 lists the tags allowed within <connection_1> and <connection_2> tags.

Table 2.5 lists the tags allowed within <participant_1> and <participant_2> tags. Notice that the <domain_id> tag is required.

Table 2.3 Domain Route Tags

	Tags within				Number of
			Description		Tags
	<domain_route>
					Allowed
	<connection_1>		Applicable to non-Connext domains.		1 (required)
			Configures the first connection. See Table 2.4.
	<connection_2>		Applicable to non-Connext domains.		1 (required)
			Configures the second connection. See Table 2.4.
	<entity_monitoring>		Enables and configures remote monitoring for the domain route. See		0 or 1
			Monitoring (Section 2.4.4).
	<participant_1>		Only applicable to Connext domains.		1 (required)
			Configures the first participant. See Table 2.5.
	<participant_2>		Only applicable to Connext domains.		1 (required)
			Configures the second participant. See Table 2.5.
	<session>		Defines a single-threaded context in which data is routed according		1 or more
			to specified routes. See Session (Section 2.4.5).		(required)
Table 2.4 Connection Tags
	Tags within				Number
			Description		of Tags
	<connection_1/2>
					Allowed
		Registers a type name and associates it with a type representation.
	<registered_type>	When you define a type in the configuration file (with the <types> tag),			0 or more
		you have to register the type in order to use it in routes. See Route
		Types (Section 2.4.6.1).
		Sequence of name/value(string) pairs that can be used to configure the
		parameters of the connection. For example:
			<property>
			<value>
	<property>		<element>		0 or 1
			<name>jms.connection.username</name>
			<value>myusername</value>
			</element>
			</value>
			</property>

2-11

Table 2.5 Participant Tags

Tags within			Number of
	Description		Tags
<participant_1/2>
			Allowed
<domain_id>	Sets the domain ID associated with the participant.		1 (required)
	Configures certain aspects of how Connext allocates internal memory.
	The configuration is per domain_route's participant and therefore
	affects all the contained Connext readers and Connext writers. For
	example:
	<domain_route name="test">
	<participant_1>
	<domain_id>0</domain_id>
	...
	<memory_management>
	<sample_buffer_min_size>X</sample_buffer_min_size>
	<sample_buffer_trim_to_size>
	true
	</sample_buffer_trim_to_size>
	</memory_management>
	</participant_1>
<memory_	...
			0 or more
management>	The <memory_management> tag can include the following tags:
	❏ sample_buffer_min_size: For all Connext readers/writers,	the
	way Connext allocates memory for samples is as follows: Connext
	pre-allocates space for samples up to size X in the reader and
	writer queues. If a sample has an actual size greater than X, the
	memory is allocated dynamically for that sample. The default size
	is DDS_LENGTH_UNLIMITED (meaning no dynamic memory is
	used; the maximum sample size is pre-allocated).
	❏ sample_buffer_trim_to_size: If set to true, after allocating
	dynamic memory for very large samples, that memory will be
	released when possible. If false, that memory will not be released
	but kept for future samples if needed. The default is false.
	This feature is useful when a data type has a very high maximum size
	(e.g., megabytes) but most of the samples sent are much smaller than
	the maximum possible size (e.g., kilobytes). In this case, the memory
	footprint is reduced dramatically, while still correctly handling the
	rare cases in which very large samples are published.

2-12

Table 2.5 Participant Tags

	Tags within		Number of
		Description	Tags
	<participant_1/2>
			Allowed
		Registers a type name and associates it with a type code. When you
	<registered_type>	define a type in the configuration file (with the <types> tag), you have	0 or more
		to register the type in order to use it in topic routes. See Route Types
		(Section 2.4.6.1).
		Sets the participant QoS.
		The contents of this tag are specified in the same manner as a Connext
		QoS profile file—see Chapter 15 in the RTI Core Libraries and Utilities
		User’s Manual.1
		If not specified, the default is used.
		You can use a <participant_qos> tag inside a <qos_library>/
		<qos_profile> previously defined in your configuration file by
		referring to it like this:
		<participant_qos base_name="MyLibrary::MyProfile"/>
	<participant_qos>	To use that profile but override just some values:	0 or 1
		<participant_qos base_name="MyLibrary::MyProfile">
		<discovery>
		<initial_peers>
		<element>udpv4://192.168.1..12</element>
		<element>shmem://</element>
		</initial_peers>
		</discovery>
		</participant_qos>
		(This applies to all QoS tags: <publisher_qos>, <subscriber_qos> in
		sessions; <datareader_qos>, <datawriter_qos> in topic routes and
		auto topic routes.)

1.See <Connext installation directory>/ndds.<version>/doc/pdf/RTI_CoreLibrariesAndUtilities_UsersManual.pdf.

2.4.3Administration

You can create a Connext application that can remotely control Routing Service. The <administration> tag is used to enable remote administration and configure its behavior.

By default, remote administration is turned off in Routing Service for security reasons. A remote administration section is not required in the configuration file.

For example:

<dds>

<routing_service>

<administration>

<domain_id>55</domain_id>

<save_path>

/home/david/mysaved_config.xml

</save_path>

</administration>

...

</routing_service>

</dds>

When remote administration is enabled, Routing Service will create a DomainParticipant, Publisher, Subscriber, DataWriter, and DataReader. These entities are used to receive commands and send responses. You can configure these entities with QoS tags within the <administration> tag.

2-13

Table 2.6 lists the tags allowed within <administration> tag. Notice that the <domain_id> tag is required.

For more details, please see Chapter 5: Administering Routing Service from a Remote Location.

Note: The command-line options used to configure remote administration take precedence over the XML configuration (see Table 3.1 on page 3-2).

Table 2.6 Remote Administration Tags

	Tags within		Number
		Description	of Tags
	<administration>
			Allowed
		A boolean that, if true, automatically triggers a save command when
		configuration updates are received. It is false by default.
	<autosave_on_	This value is mutable when an update (Section 5.2.12) command
		targets a routing service.	0 or 1
	update>
		This value is sent as part of the monitoring configuration data for the
		routing service (see Configuration Data for Routing Service (Section
		6.2.1)).
		Configures the DataReader QoS for remote administration.
		If the tag is not defined, Routing Service will use the Connext defaults
		with the following changes:
	<datareader_qos>	reliability.kind = DDS_RELIABLE_RELIABILITY_QOS (this value	0 or 1
		cannot be changed)
		history.kind = DDS_KEEP_ALL_HISTORY_QOS
		resource_limits.max_samples = 32
		Configures the DataWriter QoS for remote administration.
		If the tag is not defined, Routing Service will use the Connext defaults
	<datawriter_qos>	with the following changes:	0 or 1
		history.kind = DDS_KEEP_ALL_HISTORY_QOS
		resource_limits.max_samples = 32
	<distributed_logger>	Configures RTI Distributed Logger.	0 or 1
		See Enabling RTI Distributed Logger in Routing Service (Section 2.6).
	<domain_id>	Specifies which domain ID Routing Service will use to enable remote	1
		administration.	(required)
	<participant_qos>	Configures the DomainParticipant QoS for remote administration.	0 or 1
		If the tag is not defined, Routing Service will use the Connext defaults.
	<publisher_qos>	Configures the Publisher QoS for remote administration.	0 or 1
		If the tag is not defined, Routing Service will use the Connext defaults.
		Specifies the file that will contain the saved configuration. It is empty
		by default.
		A <save_path> must be specified if you want to use the save (Section
		5.2.10) command. If the file specified by <save_path> already exists,
	<save_path>	the file will be overwritten when save is executed.	0 or 1
		This value is mutable when an update (Section 5.2.12) command
		targets a routing service.
		This value is sent as part of the monitoring configuration data for the
		routing service (see Configuration Data for Routing Service (Section
		6.2.1)).
	<subscriber_qos>	Configures the Subscriber QoS for remote administration.	0 or 1
		If the tag is not defined, Routing Service will use the Connext defaults.

2-14

2.4.4Monitoring

You can create a Connext application that can remotely monitor the status of Routing Service. To enable remote monitoring and configure its behavior, use the <monitoring> and

<entity_monitoring> tags.

By default, remote monitoring is turned off in Routing Service for security and performance reasons. A remote monitoring section is not required in the configuration file.

For example:

<dds>

<routing_service>

<enabled>true</enabled>

<monitoring>

<domain_id>55</domain_id>

<status_publication_period>

<sec>1</sec>

</status_publication_period>

</monitoring>

...

</routing_service>

</dds>

Routing Service allows monitoring of the following kinds of entities:

❏<routing_service> (see Section 2.4.1)

❏<domain_route> (see Section 2.4.2)

❏<session> (see Section 2.4.5)

❏<route> (see Section 2.4.6)

❏<topic_route> (see Section 2.4.6)

❏<auto_route> (see Section 2.4.7)

❏<auto_topic_route> (see Section 2.4.7)

For each entity, Routing Service can publish two kinds of information:

❏Entity data

❏Entity status

Entity data provides information about the configuration of the entity. For example, the route data contains information such as the stream name and the type name. Entity data information is republished every time the entity is enabled, disabled or has configuration changes.

Entity status provides information about the operational status of an entity. This kind of information changes continuously and is computed and published periodically. For example, the route status contains information such as the route’s latency and throughput.

For more information about entity data and status, see Chapter 6: Monitoring Routing Service from a Remote Location.

When remote monitoring is enabled, Routing Service will create one DomainParticipant, one Publisher, five DataWriters for data publication (one for each kind of entity), and five DataWriters for status publication (one for each kind of entity). You can configure the QoS of these entities with the <monitoring> tag defined under <routing_service>.

The general remote monitoring parameters specified using the <monitoring> tag in

<routing_service> (except domain_id, participant_qos, publisher_qos, and datawriter_qos) can be overwritten on a per entity basis using the <entity_monitoring> tag.

For example:

<dds> <routing_service>

2-15

<monitoring>

<domain_id>55</domain_id> <status_publication_period>

<sec>1</sec>

</status_publication_period>

</monitoring>

...

<domain_route>

<entity_monitoring>

<status_publication_period> <sec>4</sec>

</status_publication_period> </entity_monitoring>

...

</domain_route> </routing_service>

</dds>

Table 2.7 lists the tags allowed within <monitoring> tag.

Table 2.7 Monitoring tags

	Tags within		Number of
		Description	Tags
	<monitoring>
			Allowed
		Configures the DataWriter QoS for remote monitoring.
	<datawriter_qos>	If the tag is not defined, Routing Service will use the Connext defaults	0 or 1
		with the following change:
		durability.kind = DDS_TRANSIENT_LOCAL_DURABILITY_QOS
	<domain_id>	Specifies which domain ID Routing Service will use to enable remote	1 (required)
		monitoring.
		Enables/disables general remote monitoring.
		Setting this value to true (default value) in the <monitoring> tag
		under <routing_service> enables monitoring in all the entities
		unless they explicitly disable it by setting this tag to false in their
	<enabled>	local <entity_monitoring> tags.	0 or 1
		Setting this tag to false in the <monitoring> tag under
		<routing_service> disables monitoring in all the Routing Service
		entities. In this case, any monitoring configuration settings in the
		entities are ignored.

2-16

Table 2.7 Monitoring tags

	Tags within		Number of
		Description	Tags
	<monitoring>
			Allowed
		Enables or disables the publication of statistics calculated within
		fixed time windows.
		By default, Routing Service only publishes the statistics
		corresponding to the window between two status publications.
		By using this tag, you can get the following additional windows:
		❏ 5 seconds
		❏ 1 minute
		❏ 5 minutes
		❏ 1 hour
	<historical_statistics>	❏ Up time (since the entity was enabled)	0 or 1
		For example:
		<historical_statistics>
		<five_second>true</five_second>
		<one_minute>true</one_minute>
		<five_minute>false</five_minute>
		<one_hour>true</one_hour>
		<up_time>false</up_time>
		</historical_statistics>
		If a window is not present (inside the tag <historical_statistics>), it
		is considered disabled.
		Historical statistics can be overwritten on a per entity basis.
		Configures the DomainParticipant QoS for remote monitoring.
	<participant_qos>	If the tag is not defined, Routing Service will use the Connext defaults	0 or 1
		with the following change:
		resource_limits.type_code_max_serialized_length = 4096
		Configures the Publisher QoS for remote monitoring.
	<publisher_qos>	If the tag is not defined, Routing Service will use the Connext	0 or 1
		defaults.
		Specifies the frequency at which status statistics are gathered.
		Statistical variables such as latency, are part of the entity status. For
		example:
		<statistics_sampling_period>
		<sec>1</sec>
		<nanosec>0</nanosec>
	<statistics_sampling_	</statistics_sampling_period>	0 or 1
	period>
		The statistics period for a given entity should be smaller than the
		publication period.
		If the tag is not defined, the period is 1 second.
		The statistics sampling period defined in <routing_service> is
		inherited by all the entities inside <routing_service>.
		An entity can overwrite the period.

2-17

Table 2.7 Monitoring tags

	Tags within		Number of
		Description	Tags
	<monitoring>
			Allowed
		Specifies the frequency at which the status of an entity is published.
		For example:
		<status_publication_period>
		<sec>3</sec>
	<status_publication_	<nanosec>0</nanosec>	0 or 1
		</status_publication_period>
	period>
		If the tag is not defined, the period is 5 seconds.
		The status publication period defined in <routing_service> is
		inherited by all the entities inside <routing_service>.
		An entity can overwrite the period.

2.4.4.1Monitoring Configuration Inheritance

The monitoring configuration defined in <routing_service> is inherited by all the entities defined inside the tag.

An entity can overwrite three elements of the monitoring configuration:

❏The status publication period

❏The statistics sampling period

❏The historical statistics windows

Each one of this three elements is inherited and can be overwritten independently using the

<entity_monitoring> tag.

For example:

<dds>

<routing_service name=”MonitoringExample”> <monitoring>

<domain_id>55</domain_id> <status_publication_period>

<sec>1</sec> </status_publication_period> <statistics_sampling_period>

<sec>1</sec>

<nanosec>0</nanosec> </statistics_sampling_period>

</monitoring>

...

<domain_route> <entity_monitoring>

<status_publication_period> <sec>4</sec>

</status_publication_period> </entity_monitoring>

...

</domain_route> </routing_service>

</dds>

In the previous example, the domain route overwrites the status publication period to 4 seconds and inherits the statistics sampling period.

2-18

Table 2.8 Entity Monitoring Tags

	Tags within					Number
			Description			of Tags
	<entity_monitoring>
						Allowed
		Enables/disables remote monitoring for a given entity.
	<enabled>	If general monitoring is disabled this value is ignored.				0 or 1
		Default value: true
		Enables or disables the publication of statistics calculated within fixed
		time windows.
		By default, Routing Service only publishes the statistics corresponding
		to the window between two status publications.
		By using this tag, you can get the following additional windows:
		❏ 5 seconds
		❏ 1 minute
		❏ 5 minutes
		❏ 1 hour
		❏ Up time (since the entity was enabled)
	<historical_statistics>	For example:				0 or 1
		<historical_statistics>
		<five_second>true</five_second>
		<one_minute>true</one_minute>
		<five_minute>false</five_minute>
		<one_hour>true</one_hour>
		<up_time>false</up_time>
		</historical_statistics>
		If a window is not present (inside the tag <historical_statistics>), it is
		considered disabled.
		If this tag is not defined, historical statistics are inherited from the
		general monitoring settings.
		Specifies the frequency at which status statistics are gathered. Statistical
		variables such as latency, are part of the entity status. For example:
		<statistics_sampling_period>
		<sec>1</sec>
		<nanosec>0</nanosec>
	<statistics_sampling_	</statistics_sampling_period>
		The statistics period for a given entity should be smaller than the				0 or 1
	period>
		publication period.
		If the tag is not defined, the period is inherited from the general
		monitoring settings.
		This tag is only present in the <entity_monitoring> tag of <route>,
		<topic_route>,	<auto_route>,	<auto_topic_route>	and
		<routing_service>.
		Specifies the frequency at which the status of an entity is published. For
		example:
		<status_publication_period>
	<status_publication_	<sec>3</sec>				0 or 1
	period>	<nanosec>0</nanosec>
		</status_publication_period>
		If the tag is not defined, its value is inherited from the general
		monitoring settings.

2-19

2.4.5Session

A <session> tag defines a single-threaded context for data routing; The data is routed according

to specified routes (Section 2.4.6) and auto routes (Section 2.4.7).

Each session will have an associated session thread that will serialize access to the routes in the session.

For example:

<dds>

...

<routing_service name=”MyRoutingService”>

...

<domain_route>

...

<session name="Session1">

...

<route name=”Route1” >

...

</route>

...

</session>

...

</domain_route>

...

</routing_service>

...

</dds>

Sessions that bridge Connext domains will create a Publisher and a Subscriber in the participants (participant_1 or participant_2) associated with the Connext domains.

Table 2.9 lists the tags allowed within a <session> tag.

Table 2.9 Session Tags

	Tags within		Number
		Description	of Tags
	<session>
			Allowed
	<auto_route>	Defines a general route based on type and stream filters. See Auto Routes	0 or more
		(Section 2.4.7).
	<auto_topic_	Defines a general Connext topic route based on type and topic filters. See Auto	0 or more
	route>	Routes (Section 2.4.7).
		Enables and configures remote monitoring for the session. See Monitoring
	<monitoring>	(Section 2.4.4) and Chapter 6: Monitoring Routing Service from a Remote	0 or 1
		Location.
		Sequence of name/value(string) pairs that can be used to configure certain
		parameters of the session. For example:
		<property>
		<value>
		<element>
	<property>	<name>com.rti.socket.timeout</name>	0 or 1
		<value>1</value>
		</element>
		</value>
		</property>
		These properties are only used in non-Connext domains.

2-20

Table 2.9 Session Tags

	Tags within		Number
		Description	of Tags
	<session>
			Allowed
		Only applicable to Connext.
		Sets the QoS associated with the session Publishers. There is one Publisher per
	<publisher_	participant.
		The contents of this tag are specified in the same manner as a Connext QoS	0 or 1
	qos>
		profile file—see the chapter Configuring QoS with XML in the RTI Core Libraries
		and Utilities User’s Manual.1
		If the tag is not defined, Routing Service will use the Connext defaults.
	<route>	Defines a data mapping between two streams. See Routes (Section 2.4.6)	0 or more
		Only applicable to Connext.
		Sets the QoS associated with the session Subscribers. There is one Subscriber
	<subscriber_	per participant.
		The contents of this tag are specified in the same manner as a Connext QoS	0 or 1
	qos>
		profile file—see the chapter Configuring QoS with XML in the RTI Core Libraries
		and Utilities User’s Manual.1
		If the tag is not defined, Routing Service will use the Connext defaults.
		Sets the mask, priority and stack size of the thread associated with this session.
		Example:
		<session>
		<thread>
		<mask>MASK_DEFAULT</mask>
		<priority>THREAD_PRIORITY_DEFAULT</priority>
		<stack_size>THREAD_STACK_SIZE_DEFAULT</stack_size>
	<thread>	</thread>	0 or 1
		...
		</session>
		Default values:
		mask = MASK_DEFAULT
		priority = THREAD_PRIORITY_DEFAULT
		stack_size = THREAD_STACK_SIZE_DEFAULT
	<topic_route>	Defines a data mapping between two Connext topics. See Routes (Section	0 or more
		2.4.6).

2-21

Table 2.9 Session Tags

	Tags within		Number
		Description	of Tags
	<session>
			Allowed
		Configures the WaitSet used to sleep and notify the session thread when data
		is available.
		Example:
		<session>
		<wait_set>
		<max_event_count>5</max_event_count>
		<max_event_delay>
		<sec>1</sec>
		<nanosec>0</nanosec>
		</max_event_delay>
	<wait_set>	</wait_set>	0 or 1
		...
		</session>
		In the previous example, the session thread wakes up and tries to read data
		after a 1 second timeout expires (max_event_delay) or after it has been notified
		five times across routes that new data is available (max_event_count).
		Default values:
		max_event_count = 1
		max_event_delay.sec = DURATION_INFINITE_SEC
		max_event_delay.nanosec = DURATION_INFINITE_NSEC

1.See <Connext installation directory>/ndds.<version>/doc/pdf/RTI_CoreLibrariesAndUtilities_UsersManual.pdf.

2.4.6Routes

A route explicitly defines a mapping between an “input” data stream on one domain and an “output” data stream on the other domain.

For example, the following route defines a mapping between a Connext topic called Square and a JMS queue called Square.

<dds>

...

<routing_service>

...

<domain_route> <participant_1>

<domain_id>54</domain_id> </participant_1>

<connection_2 plugin_name=”my_adapter_library::jms> </connection_2>

...

<session name="Session1">

...

<route name="DDSSquaresToJMSSquares">

<dds_input participant=”1”>

<topic_name>Square</topic_name>

<registered_type_name>ShapeType</registered_type_name>

...

</dds_input>

<output>

<stream_name>Square</topic_name>

<registered_type_name>ShapeType</registered_type_name>

2-22

...

</output>

...

</route>

</session>

...

</domain_route>

...

</routing_service>

...

</dds>

Connext inputs and outputs within a route are defined using the XML tags <dds_input> and <dds_output>. Input and outputs from other data domains are defined using the tags <input> and <output>. A topic route is a special kind of route that defines a mapping between an “input” topic on one Connext domain and an “output” topic on other Connext domain. For example, the following topic route will subscribe to topic Square on domain 54 and will republish those samples on domain 55 as samples of topic Circle.

<dds>

...

<routing_service>

...

<domain_route> <participant_1>

<domain_id>54</domain_id> </participant_1>

<participant_2> <domain_id>55</domain_id>

</participant_2>

...

<session name="Session1">

...

<topic_route name="SquaresToCircles">

<input participant=”1”>

<topic_name>Square</topic_name> <registered_type_name>ShapeType</registered_type_name>

...

</input>

<output>

<topic_name>Circle</topic_name>

<registered_type_name>ShapeType</registered_type_name>

...

</output>

...

</topic_route>

</session>

...

</domain_route>

...

</routing_service>

...

</dds>

In the previous example, the direction of the mapping is defined by the attribute participant of the tag <input>. Therefore, to change the above example to read Squares from domain 55 and

2-23

write Circles on domain 54, we would use <input participant=”2”>. There is an equivalent attribute for non-Connext inputs called connection.

Inputs and outputs in a route or topic route have an associated StreamReader and StreamWriter, respectively. For Connext domains, the StreamReader will contain a DataReader and the StreamWriter will contain a DataWriter. The Connext DataReaders and DataWriters belong to the corresponding session’s Subscriber and Publisher.

The read and write operations in a route will be performed in the context of the thread associated with the session.

Routes vs. Auto Routes: A route is an explicit route of data for two specific streams. An auto route (defined with a different tag, <auto_route>) is a way to automatically create routes based on filters—see Auto Routes (Section 2.4.7).

Table 2.10 lists the tags allowed within a <route>.

Table 2.11 lists the tags allowed within a <topic_route>.

Table 2.12 lists the tags allowed within the input and output tags in a <route> tag.

Table 2.13 lists the tags allowed within the Connext input and output tags. in a <route> or

<topic_route> tag.

Table 2.10 Route Tags

			Number
	Tags within <route>	Description	of Tags
			Allowed
	<dds_input>	Only applicable to Connext inputs.	1
		Defines the route’s input topic. See Table 2.13.	(required)
	<dds_output>	Only applicable to Connext outputs.	1
		Defines the route’s output topic. See Table 2.13.	(required)
		Configures remote monitoring for the route. See Monitoring (Section
	<entity_monitoring>	2.4.4) and Chapter 6: Monitoring Routing Service from a Remote	0 or 1
		Location.
	<input>	Only applicable to non-Connext inputs.	1
		Defines the route’s input stream. See Table 2.13.	(required)
	<output>	Only applicable to non-Connext outputs.	1
		Defines the route’s output stream. See Table 2.13.	(required)
		When this tag is true, the data samples read from the input stream are
		written into the output stream with the same timestamp that was
	<publish_with_	associated with them when they were made available in the input
		domain.	0 or 1
	original_timestamp>
		This option may not be applicable in some adapter implementations in
		which the concept of timestamp is unsupported.
		Default: false
		Defines if the input connection will use types discovered in the output
		connection and vice versa for the creation of StreamWriters and
	<route_types>	StreamReaders in the route.	0 or 1
		See Discovering Types (Section 2.4.6.3).
		Default: false
	<transformation>	Sets a data transformation to be applied for every data sample (see	0 or 1
		Data Transformation (Section 2.4.6.5)).

2-24

Table 2.11 Topic Route Tags

	Tags within			Number
		Description		of Tags
	<topic_route>
				Allowed
		Configures remote monitoring for the topic route. See Monitoring
	<entity_monitoring>	(Section 2.4.4) and Chapter 6: Monitoring Routing Service from a		0 or 1
		Remote Location.
	<input>	Defines the topic route’s input topic. See Table 2.13.		1 (required)
	<output>	Defines the topic route’s output topic. See Table 2.13.		1 (required)
		Indicates whether or not disposed samples (NOT_ALIVE_DISPOSE)
		must be propagated by the topic route.
	<propagate_dispose>	This action maybe be overwritten by the execution of a		0 or 1
		transformation.
		Default: true
		Indicates whether or not NOT_ALIVE_NO_WRITERS samples must
		be propagated by the topic route by using the unregister_instance()
	<propagate_	operation		0 or 1
	unregister>	This action maybe be overwritten by the execution of a
		transformation.
		Default: true
		Writes the data sample as if they came from its original writer. Setting
	<publish_with_	this option to true allows having redundant routing services and		0 or 1
	original_info>	prevents the applications from receiving duplicate samples.
		Default: false
	<publish_with_	When this tag is set to true, the data samples are written with their
		original source timestamp.		0 or 1
	original_timestamp>
		Default: false
		Defines if the input domain will use types discovered in the output
		domain and vice versa for the creation of DataWriters and
	<route_types>	DataReaders in the topic route.		0 or 1
		See Discovering Types (Section 2.4.6.3).
		Default: false
	<transformation>	Sets a data transformation to be applied for every data sample (see		0 or 1
		Data Transformation (Section 2.4.6.5)).
Table 2.12 Input and Output Tags for a Route
	Tags within			Number
	<input> and	Description		of Tags
	<output>			Allowed
		Specifies when to create the StreamReader/StreamWriter.
	<creation_mode>	Default: IMMEDIATE		0 or 1
		See Creation Modes—Controlling when StreamReaders and
		StreamWriters are Created (Section 2.4.6.4).
		Sequence of name/value(string) pairs that can be used to configure
		certain parameters of the StreamReaders/StreamWriters. For example:
		<property>
		<value>
	<property>	<element>		0 or 1
		<name>com.rti.socket.port</name>
		<value>16556</value>
		</element>
		</value>
		</property>