Dynamic Routing Guide
|
Ultra Messaging (Version 6.12.1)
© Copyright Informatica LLC 2004-2019.
This document explains design concepts and product implementation for the Ultra Messaging Dynamic Routing Option (DRO).
This software and documentation are provided only under a separate license agreement containing restrictions on use and disclosure. No part of this document may be reproduced or transmitted in any form, by any means (electronic, photocopying, recording or otherwise) without prior consent of Informatica LLC.
A current list of Informatica trademarks is available on the web at https://www.informatica.com/trademarks.html.
Portions of this software and/or documentation are subject to copyright held by third parties. Required third party notices are included with the product.
This software is protected by patents as detailed at https://www.informatica.com/legal/patents.html.
The information in this documentation is subject to change without notice. If you find any problems in this documentation, please report them to us in writing at Informatica LLC 2100 Seaport Blvd. Redwood City, CA 94063.
Informatica products are warranted according to the terms and conditions of the agreements under which they are provided.
INFORMATICA LLC PROVIDES THE INFORMATION IN THIS DOCUMENT "AS IS" WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING WITHOUT ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OR CONDITION OF NON-INFRINGEMENT.
The Ultra Messaging Dynamic Routing Option (DRO) consists of a daemon called the "UM Router" (or just the DRO) that bridges disjoint Topic Resolution Domains (TRDs) by effectively forwarding control and user traffic between them. Thus, the UM Router facilitates WAN routing where multicast routing capability is absent, possibly due to technical obstacles or enterprise policies. (FYI: a historical name for the UM Router is "Twenty Nine West Gateway Daemon" or "tnwgd". In the documentation you will see various abbreviations that include "tnwg".)
The UM Router includes the following features:
The following features are not fully supported in this release of the UM Router:
If you desire any of these features or any configuration or topology not presented in this document, please contact Informatica Ultra Messaging Support for possible alternatives.
The UM Router uses interfaces, called portals, through which to pass data. A UM Router consists of two or more bidirectional portals that may be one of two types:
The figure below shows a simple UM Router use case, where two UM Routers bridge an ISP to connect two TRDs.
You configure portals in the UM Router's XML configuration file, specifying the portal's name, cost, UM Configuration, Access Control Lists and other attributes. See XML Configuration Reference.
Since topic resolution uses UDP, sources and receivers must have UDP connectivity to each other. When they do, we consider them to be in the same topic resolution domain (TRD). More specifically, UM contexts must satisfy the following two requirements to belong to the same topic resolution domain.
For example, two contexts on separate machines in the same LAN are not in the same topic resolution domain if they use different resolver addresses. See Multicast Resolver Network Options. A topic resolution domain can span a WAN if the UM contexts on each side of a firewall use the same UM configuration and the firewall allows UDP traffic (multicast or unicast) to pass.
Each endpoint portal must identify its associated topic resolution domain with a domain-id the UM Router's XML configuration file, as in the example below. All portals in the same TRD must have the same domain-id, and different TRDs networked together via UM Routers must have domain-ids unique to each other.
To resolve a topic across a UM Router (described in Basic UM Router Operation), the UM Router creates, within portals, proxy sources and proxy receivers (shown in the figure below by their dashed lines). These proxies behave like their UM counterparts; they resolve topics on the TRDs like normal sources and receivers, and the UM Router internally passes data from one portal to the other. However unlike regular sources, proxy sources do not have retransmission retention buffers normally used for Late Join or OTR.
Portals exist while the UM Router is running, however, the UM Router creates proxy sources and receivers during topic resolution and deletes them when the topic is retired.
In multiple-UM Router environments where more than one UM Router can provide possible messaging pathways, the UM Routers are able to cooperatively determine and establish optimal routes. Also, the UM Router network is able to detect link or other UM Router outages and automatically reroute traffic as needed. See Routing Topologies for more information.
The diagram below shows a UM Router bridging topic resolution domains TRD1 and TRD2, for topic AAA, in a direct link configuration. Endpoint E1 contains a proxy receiver for topic AAA and endpoint E2 has a proxy source for topic AAA.
To establish topic resolution in an already-running UM Router, the following sequence typically occurs in an example like the above figure.
When a UM Router starts, its endpoint portals issue a brief series of Topic Resolution Request messages to their respective topic resolution domains. This provokes quiescent receivers (and wildcard receivers) into sending Use Query Responses, indicating interest in various topics. Each portal then records this interest.
After a UM Router has been running, endpoint portals issue periodic Topic Use Queries and Pattern Use Queries (collectively referred to as simply Use Queries). Use Query Responses from UM contexts confirm that the receivers for these topics indeed still exist, thus maintaining these topics on the interest list. Autonomous TQRs also refresh interest and have the effect of suppressing the generation of Use Queries.
In the case of multi-hop UM Router configurations, UM Routers cannot detect interest for remote contexts via Use Queries or TQRs. They do this instead via Interest Messages. An endpoint portal generates periodic interest messages, which are picked up by adjacent UM Routers (i.e., the next hop over), at which time interest is refreshed.
You can adjust intervals, limits, and durations for these topic resolution and interest mechanisms via UM Router configuration options (see XML Configuration Reference).
To maintain a reliable connection, peer portals exchange UM Router Keepalive signals. Keepalive intervals and connection timeouts are configurable on a per-portal basis. You can also set the UM Router to send keepalives only when traffic is idle, which is the default condition. When both traffic and keepalives go silent at a portal ingress, the portal considers the connection lost and disconnects the TCP link. After the disconnect, the portal tries to reconnect. See refeatewaykeepalive.
UM Router proxy sources on endpoint portals, when deleted, send out a series of final advertisements. A final advertisement tells any receivers, including proxy receivers on other UM Routers, that the particular source has gone away. This triggers EOS and clean-up activities on the receiver relative to that specific source, which causes the receiver to begin querying according to its topic resolution configuration for the sustaining phase of querying.
In short, final advertisements announce earlier detection of a source that has gone away, instead of transport timeout. This causes a faster transition to an alternative proxy source on a different UM Router if there is a change in the routing path.
The domain-id is used by Interest Messages and other internal and UM Router-to-UM Router traffic to ensure forwarding of all messages (payload and topic resolution) to the correct recipients. This also has the effect of not creating proxy sources/receivers where they are not needed. Thus, UM Routers create proxy sources and receivers based solely on receiver interest.
If more than one source sends on a given topic, the receiving portal's single proxy receiver for that topic receives all messages sent on that topic. The sending portal, however creates a proxy source for every source sending on the topic. The UM Router maintains a table of proxy sources, each keyed by an Originating Transport ID (OTID), enabling the proxy receiver to forward each message to the correct proxy source. An OTID uniquely identifies a source's transport session, and is included in topic advertisements.
When an application creates a source, it is configured to use one of the UM transport types. When a DRO is deployed, the proxy sources are also configured to use one of the UM transport types. Although users often use the same transport type for sources and proxy sources, this is not necessary. When different transport types are configured for source and proxy source, the DRO is performing a protocol conversion.
When this is done, it is very important to configure the transports to use the same maximum datagram size. If you don't, the DRO can drop messages which cannot be recovered through normal means. For example, a source in TRD1 can be configured for TCP, which has a default maximum datagram size of 65536. If a DRO's remote portal is configured to create LBT-RU proxy sources, that has a default maximum datagram size of 8192. If the source sends a user message of 10K, the TCP source will send it as a single fragment. The DRO will receive it and will attempt to forward it on an LBT-RU proxy source, but the 10K fragment is too large for LBT-RU's maximum datagram size, so the message will be dropped.
The solution is to override the default maximum datagram sizes to be the same. Informatica generally does not recommend configuring UDP-based transports for datagram sizes above 8K, so it is advisable to set the maximum datagram sizes of all transport types to 8192, like this:
context transport_tcp_datagram_max_size 8192 context transport_lbtrm_datagram_max_size 8192 context transport_lbtru_datagram_max_size 8192 context transport_lbtipc_datagram_max_size 8192 source transport_lbtsmx_datagram_max_size 8192
See configuration options: transport_tcp_datagram_max_size (context), transport_lbtrm_datagram_max_size (context), transport_lbtru_datagram_max_size (context), transport_lbtipc_datagram_max_size (context), and transport_lbtsmx_datagram_max_size (source).
Also see Message Fragmentation and Reassembly.
Final note: the resolver_datagram_max_size (context) option also needs to be made the same in all instances of UM, including DROs.
UM can resolve topics across a span of multiple UM Routers. Consider a simple example UM Router deployment, as shown in the following figure.
In this diagram, UM Router A has two endpoint portals connected to topic resolution domains TRD1 and TRD2. UM Router B also has two endpoint portals, which bridge TRD2 and TRD3. Endpoint portal names reflect the topic resolution domain to which they connect. For example, UM Router A endpoint E2 interfaces TRD2.
TRD1 has a source for topic AAA, and TRD3, an AAA receiver. The following sequence of events enables the forwarding of topic messages from source AAA to receiver AAA.
The UM Router supports topic resolution for wildcard receivers in a manner very similar to non-wildcard receivers. Wildcard receivers in a TRD issuing a WC-TQR cause corresponding proxy wildcard receivers to be created in portals, as shown in the following figure. The UM Router creates a single proxy source for pattern match.
Forwarding a message through a UM Router incurs a cost in terms of latency, network bandwidth, and CPU utilization on the UM Router machine (which may in turn affect the latency of other forwarded messages). Transiting multiple UM Routers adds even more cumulative latency to a message. Other UM Router-related factors such as portal buffering, network bandwidth, switches, etc., can also add latency.
Factors other than latency contribute to the cost of forwarding a message. Consider a message that can be sent from one domain to its destination domain over one of two paths. A three-hop path over 1Gbps links may be faster than a single-hop path over a 100Mbps link. Further, it may be the case that the 100Mbps link is more expensive or less reliable.
You assign forwarding cost values on a per-portal basis. When summed over a path, these values determine the cost of that entire path. A network of UM Routers uses forwarding cost as the criterion for determining the best path over which to resolve a topic.
UM Routers have an awareness of other UM Routers in their network and how they are linked. Thus, they each maintain a topology map, which is periodically confirmed and updated. This map also includes forwarding cost information.
Using this information, the UM Routers can cooperate during topic resolution to determine the best (lowest cost) path over which to resolve a topic or to route control information. They do this by totaling the costs of all portals along each candidate route, then comparing the totals.
For example, the following figure shows two possible paths from TRD1 to TRD2: A-C (total route cost of 11) and B-D (total route cost of 7). In this case, the UM Routers select path B-D.
If a UM Router or link along path B-D should fail, the UM Routers detect this and reroute over path A-C. Similarly, if an administrator revises cost values along path B-D to exceed a total of 12, the UM Routers reroute to A-C.
If the UM Routers find more than one path with the same lowest total cost value, i.e., a "tie", they select the path based on a node-ID selection algorithm. Since administrators do not have access to node IDs, this will appear to be a pseudo-random selection.
You can configure multiple UM Routers in a variety of topologies. Following are several examples.
The Direct Link configuration uses a single UM Router to directly connect two TRDs. For a configuration example, see Direct Link Configuration.
A Single Link configuration connects two TRDs using a UM Router on each end of an intermediate link. The intermediate link can be a "peer" link, or a transit TRD. For configuration examples, see Peer Link Configuration and Transit TRD Link Configuration.
Parallel Links offer multiple complete paths between two TRDs. However, UM will not load-balance messages across both links. Rather, parallel links are used for failover purposes. You can set preference between the links by setting the primary path for the lowest cost and standby paths at higher costs. For a configuration example, see Parallel Links Configuration.
Loops let you route packets back to the originating UM Router without reusing any paths. Also, if any peer-peer links are interrupted, the looped UM Routers are able to find an alternate route between any two TRDs.
The Loop and Spur has a one or more UM Routers tangential to the loop and accessible only through a single UM Router participating in the loop. For a configuration example, see Loop and Spur Configuration.
Adding a TRD to the center of a loop enhances its rerouting capabilities.
A Star with a centralized TRD does not offer rerouting capabilities but does provide an economical way to join multiple disparate TRDs.
The Star with a centralized UM Router is the simplest way to bridge multiple TRDs. For a configuration example, see Star Configuration.
The Mesh topology provides peer portal interconnects between many UM Routers, approaching an all-connected-to-all configuration. This provides multiple possible paths between any two TRDs in the mesh. Note that this diagram is illustrative of the ways the UM Routers may be interconnected, and not necessarily a practical or recommended application. For a configuration example, see Mesh Configuration.
The Palm Tree has a set of series-connected TRDs fanning out to a more richly meshed set of TRDs. This topology tends to pass more concentrated traffic over common links for part of its transit while supporting a loop, star, or mesh near its terminus.
Similar to the Palm Tree, the Dumbbell has a funneled route with a loop, star, or mesh topology on each end.
When designing UM Router networks, do not use any of the following topology constructs.
Two peer-to-peer connections between the same two UM Routers:
Two endpoint connections from the same UM Router to the same TRD:
Assigning two different Domain ID values (from different UM Routers) to the same TRD:
You must install the UM Dynamic Routing Option with its companion Ultra Messaging UMS, UMP, or UMQ product, and versions must match. While most UM features are compatible with the UM Router, some are not. Following is a table of features and their compatibilities with the UM Router.
UM Feature | UM Router Compatible? | Notes |
---|---|---|
Transport Acceleration | Yes | |
Hot Failover (HF) | Yes | The UM Router can pass messages sent by HF publishers to HF receivers, however the UM Router itself cannot be configured to originate or terminate HF data streams. |
Hot Failover across contexts (HFX) | Yes | |
Late Join | Yes | |
Message Batching | Yes | |
Monitoring/Statistics | Yes | |
Multicast Immediate Messaging (MIM) | Yes | |
Multi-Transport Threads | No | |
Off-Transport Recovery (OTR) | Yes | |
Ordered Delivery | Yes | |
Pre-Defined Messaging (PDM) | Yes | |
Request/Response | Yes | |
Self-Describing Messaging (SDM) | Yes | |
Source Side Filtering | Yes | The UM Router supports transport source side filtering. You can activate this either at the originating TRD source, or at a downstream proxy source. |
Transport LBT-IPC | Yes | |
Transport LBT-RDMA | Yes | |
Transport LBT-RM | Yes | |
Transport LBT-RU | Yes | |
Transport LBT-SMX | Partial | The UM router does not support proxy sources sending data via LBT-SMX. Any proxy sources configured for LBT-SMX will be converted to TCP, with a log message warning of the transport change. The UM Router does accept LBT-SMX ingress traffic to proxy receivers. |
Transport TCP | Yes | |
Transport TCP-LB | Yes | |
JMS, via UMQ broker | No | |
UM Spectrum | Yes | The UM Router supports UM Spectrum traffic, but you cannot implement Spectrum channels in UM Router proxy sources or receivers. |
UMP Implicit/Explicit Acknowledgements | Yes | |
UMP Persistent Store | Yes | |
UMP Proxy Sources | Yes | |
UMP Quorum Consensus | Yes | |
UMP Registration ID/Session Management | Yes | |
UMP Receiver-Paced Persistence (RPP) | Yes | |
UMP Store Failover | Yes | |
UMQ Brokered Queuing | No | |
UMQ Ultra Load Balancing (ULB) | No | |
Ultra Messaging Desktop Services (UMDS) | Not for client connectivity to the UMDS server | |
Ultra Messaging Manager (UMM) | Yes | Not for UM Router management |
UM SNMP Agent | No | |
UMCache | No | |
Wildcard Receivers | Yes | |
Zero Object Delivery (ZOD) | Yes |
When the UM Router daemon launches, it uses configuration option settings to determine its behavior and expectations. You specify option values in an XML configuration file, and reference the file from a command line argument.
Typically, you have a separate XML configuration file for each UM Router, which contains structured configuration elements that describe aspects of the UM Router. Within this XML configuration file, each endpoint portal definition points to a UM configuration file, which allow the portal to properly connect to its TRD.
When developing messaging applications that use Ultra Messaging and, in particular, the UM Router, please observe the following guidelines.
An important part to successfully implementing UM Routers is prudent and error-free naming of TRDs, UM Routers, portals, etc., as well as correct identification of IP addresses and ports. It is good practice to first design the UM Router network by defining all connections and uniquely naming all UM Routers, portals, and TRDs. This works well as a diagram similar to some examples presented in this document. Include the following names and parameters in your design diagram:
For example, a well-prepared UM Router design could look like the following figure.
A network of UM Routers uses forwarding cost as the criterion for determining the best (lowest cost) path over which to resolve a topic and route data. Forwarding cost is simply the sum of all portal costs along a multi-UM Router path. Thus, total cost for the single path in the above example is 34. (Note that this is a non-real-world example, since costs are pointless without alternate routes to compare to.) You assign portal costs via the <cost>
configuration option.
After the UM Router network calculates its paths, if a new lower-cost source becomes available, receivers switch to that path.
You can apply Access Control Lists (ACL) to a UM Router's portals to filter traffic by certain topics, transports, topic patterns, multicast groups, etc. You configure ACLs in a UM Router's XML configuration file, as children of an <endpoint>
or <peer>
portal. As traffic arrives at the portal, the portal either forwards it or rejects it per ACL criteria.
Inbound ACLs determine what information to forward to other portals in the UM Router, while Outbound ACLs determine (by topic) what information from other portals that this portal can send out the UM Router. Each portal (endpoint or peer) can have up to one inbound ACL and one outbound ACL.
An ACL can contain one or more Access Control Entries (ACEs). ACEs are the filters that let you match (and accept or reject based on), criteria elements. For example, to accept only messages for topic ABC:
Possible ACE condition elements are:
<multicast-group/>
* <pcre-pattern>
(PCRE wildcard patterns) <regex-pattern>
(Regex wildcard patterns) <source-ip/>
* <tcp-source-port/>
* <topic>
<transport/>
* <udp-destination-port/>
* <udp-source-port/>
* <xport-id/>
* (for LBT-IPC traffic) These items apply to only inbound ACLs, and are ignored if used with an outbound ACL.
The above elements are all children of the <ace>
element. When an ACL has multiple ACE entries, the UM Router goes down the list until it finds a match. It then accepts (forwards) or rejects, and is done with that ACL. An implicit "reject all" is at the end of every ACL, so the UM Router rejects any topic not matched. If you place multiple conditions within an ACE, the UM Router performs an "and" operation with them.
Note that the portal ignores a condition element if a) it is inbound-only and used in an outbound ACL, or b) it simply does not apply (such as a <udp-source-port/>
if the transport is TCP).
Also note that ACLs can affect topic resolution traffic as well as user messages. They can, for example, block a topic (which prevents the creation of proxy receivers) and, thus, protect remote TRDs from unwanted queries and advertisements. This effect does not apply to wildcard receivers, however, because ACLs match only on discrete topics. Thus, while ACLs can operate on specific topic traffic derived from wildcard topic resolution, they cannot prevent pattern interest from propagating throughout the network.
Consider the following example, where we configure a portal to forward on specific topics. This example also illustrates the parent/child hierarchy for ACLs, ACEs, and ACE conditions.
The above example shows each topic match in a separate ACE. When topic "GHI" arrives, the portal finds a match in the third ACE and forwards the topic. (Placing all three <topic>
s in a single ACE would never match anything.) Also note that "DEF" is forwarded only if it uses an LBT-RM transport.
Since the behavior for multiple ACEs is "first match, then done", list ACEs in a specific-to-general order. For the example below, to forward topic "ABC123" but reject similar topics such as "ABCD123" or "ABCE123", list the ACE for "ABC123" first (as done below). If the ACE to reject "ABC.*123" was listed first, it would also (undesirably) match and reject "ABC123".
You can also filter on certain transport types to accept multicast traffic but reject tcp traffic, as shown below.
The UM Router offers a wide choice of timer and interval options to fine tune its behavior and performance. There are interactions and dependencies between some of these, and if misconfigured, they may cause race or failure conditions.
This manual's description of configuration options (see XML Configuration Reference), includes identification of such relationships. Please heed them.
Multicast Immediate Messages (MIMs) may pass through the UM Router. You cannot filter MIMs with Access Control Lists (ACL)-MIMs are forwarded to all TRDs. Informatica does not recommend using MIM for messaging traffic across the UM Router. MIM is intended for short-lived topics and applications that cannot tolerate a delay between source creation and the sending of the first message. See also Multicast Immediate Messaging.
The UM Router supports UMP persistence by routing all necessary control and retransmission channels along with transport and topic resolution traffic. A typical implementation places the UMP persistent store in the same TRD as its registered source, as shown in the following figure.
The UM Router also supports UMP implementations with the store located in a receiver's TRD, as shown in the following figure.
Note: For more reliable operation when using UMP with UM Routers, Informatica recommends enabling OTR.
The UM Router supports sources and receivers configured for Late Join and/or Off-Transport Recovery (OTR). Retransmission requests and subsequent retransmissions are conducted across the entire path through the UM Router network. A UM Router's proxy sources do not have Late-Join/OTR retention buffers and hence, are not able to provide recovered messages.
Topic resolution can sometimes remain in a quiescent phase due to link interruption, preventing needed re-subscription topic resolution activity. Two ways you can address this are:
Through a network of UM Routers, a topic traverses a separate session for each link along its path. Thus, the UM Router reports BOS/EOSs based on the activity between the proxy source transport and its associated receiver. There is no end-to-end, application-to-application reporting of the data path state. Also, in the case of multiple topics being assigned to multiple sessions, topics may find themselves with different session mates from hop to hop. Of course, this all influences when, and for which transport session, a topic's BOSs and EOSs are issued.
The UM router can create a situation where a "reliable" transport (TCP or LBT-IPC) can experience out-of-order message delivery.
The UM router can perform a "protocol conversion" function. I.e. an originating source can use a UDP-based protocol (LBT-RM or LBT-RU), but the proxy source for a remote receiver can use a "reliable" protocol (TCP or LBT-IPC). With a UDP-based protocol, messages can arrive to the UM Router network out of order, usually due to packet loss and recovery. However, when those out-of-order messages are forwarded across a "reliable" protocol (TCP or LBT-IPC), the receiver does not expect the sequence number gap, and immediately declares the out-of-order messages as unrecoverable loss. This, in spite of the fact that the missing message arrives shortly thereafter.
Starting in UM version 6.12, there are two new configuration options: transport_tcp_dro_loss_recovery_timeout (receiver) and transport_lbtipc_dro_loss_recovery_timeout (receiver), which modify the receiver's behavior. Instead of declaring a gap immediately unrecoverable, a delay is introduced which is similar to what a UDP-based receiver uses to wait for lost and retransmitted datagrams. If the missing message arrives within the delay time, the messages are delivered to application without loss.
Be aware that this functionality is only used with "reliable" protocols published by a UM Router's proxy source. If this delay feature is enabled, it will not apply to a "reliable" protocol that is received directly from the originating source.
Note however that you can get genuine gaps in the "reliable" data stream without recovery. For example, an overloaded UM Router can drop messages. Or a UM Router's proxy receiver can experience unrecoverable loss. In that case, the delay will have to expire before the missing messages are declared unrecoverable and subsequent data is delivered.
Following are example configurations for a variety of UM Router topologies. These are the topology examples presented Routing Topologies.
In a real-world situation, you would have UM Router XML configuration files with their portal interfaces referencing complete UM configuration files. However, for these examples, the referred domain configuration files are simplified to contain only information relevant to the applicable UM Router. As part of this simplification, domain configuration files show interfaces for only one or two transport types.
Also, IP addresses are provided in some cases and omitted in other cases. This is because initiator peer portals need to know the IP addresses (and port numbers) of their corresponding acceptor portals to establish connections, whereas endpoint portals communicate via topic resolution and thus, do not need to know IP addresses.
This example uses a UM Router to connect two topic resolution domain LANs.
TRD1 Configuration
This UM configuration file, trd1.cfg, describes TRD1 and is referenced in the UM Router configuration file.
G1 Configuration
This UM Router configuration file defines two endpoint portals. In the daemon section, we have turned on monitoring for the all endpoint portals in the UM Router. The configuration specifies that all statistics be collected every 5 seconds and uses the lbm transport module to send statistics to your monitoring application, which runs in TRD1. See also UM Concepts, Monitoring UMS. The Web Monitor has also been turned on (port 15304) to monitor the performance of the UM Router.
TRD2 Configuration
The configuration file trd2.cfg could look something like this.
In cases where the UM Router connection between two TRDs must tunnel through a WAN or TCP/IP network, you can implement a UM Router at each end, as shown in the example below.
TRD1 Configuration
G1 Configuration
Following is an example of two companion peer portals (on different UM Routers) configured via UM Router XML configuration file for a single TCP setup. Note that one must be an initiator and the other, an acceptor.
G2 Configuration
TRD2 Configuration
This example, like the previous one, configures two localized UM Routers tunneling a connection between two TRDs, however, the UM Routers in this example are tunneling through an intermediate TRD. This has the added effect of connecting three TRDs.
TRD1 Configuration
G1 Configuration
Following is an example of two companion peer portals (on different UM Routers) configured via UM Router XML configuration file for a single TCP setup. Note that one must be an initiator and the other, an acceptor.
TRD2 Configuration
G2 Configuration
TRD3 Configuration
This example is similar in purpose to the single link, peer-to-peer example, except that a second pair of UM Routers is added as a backup route. You can set one of these as a secondary route by assigning a higher cost to portals along the path. In this case we set G3 and G4's portal costs to 5, forcing the lower route to be selected only if the upper (G1, G2) route fails.
Also note that we have configured the peer portals for the leftmost or odd-numbered UM Routers as initiators, and the rightmost or even-numbered UM Router peers as acceptors.
TRD1 Configuration
G1 Configuration
G2 Configuration
G3 Configuration
G4 Configuration
TRD2 Configuration
TRD1 Configuration
G1 Configuration
G2 Configuration
TRD2 Configuration
TRD3 Configuration
G3 Configuration
G4 Configuration
TRD4 Configuration
G5 Configuration
TRD5 Configuration
This network consists of four TRDs. Within each TRD, full multicast connectivity exists. However, no multicast connectivity exists between the four TRDs.
G1 Configuration
The configuration for this UM Router also has transport statistics monitoring and the WebMonitor turned on.
TRD1 Configuration
TRD2 Configuration
TRD3 Configuration
TRD4 Configuration
The mesh topology utilizes many connections between many nodes, to provide a variety of alternate routes. However, meshes are not the best solution in many cases, as unneeded complexity can increase the chance for configuration errors or make it more difficult to trace problems.
TRD1 Configuration
G1 Configuration
G2 Configuration
G3 Configuration
TRD2 Configuration
TRD3 Configuration
G4 Configuration
G5 Configuration
Within the UM Router configuration file, the endpoint portal's <lbm-config>
element lets you import configurations from either a plain text or XML UM configuration file. However, using the XML type of UM configuration files provides the following advantages over plain text UM configuration files:
<daemon>
element instead of within each portal's configuration.
When setting endpoint options, first name the context of each endpoint in the UM Router's XML configuration file.
Then assign configuration templates to those contexts in the UM XML configuration file.
You specify the unique options for each of this UM Router's two endpoints in the UM XML configuration <templates>
section used for G1-E1-options and G1-E2-options.
One advantage of using UM XML configuration files with the UM Router is the ability to assign unique UM attributes to the topics and contexts used for the proxy sources and receivers (which plain text UM configuration files cannot do). The following example shows how to assign a different LBTRM multicast address to a source based on its topic.
Create a new UM XML configuration template for the desired topic name.
Then include this template in the <application>
element associated with the UM Router.
It is also possible to assign UM attributes directly in the <application>
tag. For example, the following specifies that a particular topic should use an LBT-RU transport.
The following sample configuration incorporates many of the examples mentioned above. The UM Router applies options to all UM objects created. The UM XML configuration file overwrites these options for two specific topics. The first topic, LBTRM_TOPIC, uses a different template to change its transport from TCP to LBTRM, and to set an additional property. The second topic, LBTRU_TOPIC, also changes its transport from TCP to a new value. However, its new attributes are applied directly in its associated topic tag, instead of referencing a template. In addition, this sample configuration assigns the rm-source template to all sources and receivers associated with the context endpt_1.
This UM Router uses the above XML UM configuration file, sample-config.xml, to set its UM options. It has three endpoints, one of which has the context endpt_1.
To run the UM Router, ensure the following:
Typically, you run the UM Router with one configuration file argument, for example:
(FYI: "tnwgd" stands for "Twenty Nine West Gateway Daemon", a historical name for the UM Router.)
The UM Router logs version information on startup. The following is an example of this information:
Help for the UM Router command line can be obtained by entering "tnwgd -h". Brief help for the UM Router configuration file can be obtained by entering "tnwgd -d", which prints the DTD contents. (FYI: "tnwgd" stands for "Twenty Nine West Gateway Daemon", a historical name for the UM Router.)
There are two executables for the UM Router, each with it's own man page:
The tnwgd executable can be run interactively from a command prompt or from a script/batch file. For use as a Windows Service, see Tnwgds Man Page.
-d
or --dump-dtd
. After dumping the DTD, tnwgd exits instead of providing UM Router services as usual. See UM Router Configuration DTD for the DTD with comments removed.-v
or --validate
options. After attempting validation, tnwgd exits instead of providing UM Router services as usual. The exit status will be 0 for a configuration file successfully validated by the DTD, and non-zero otherwise.-h
or --help
.-f
or --detach
option is given on Unix, tnwgd instead forks and detaches the child process from the controlling terminal, and the parent exits immediately.
The tnwgds executable is for use as a Windows Service. The service can be installed as a service by the Windows package installer.
Alternatively, the tnwgds executable can be run interactively from a command prompt to install the service or to change certain configuration elements. See UM Daemons as Windows Services for more details.
configfile
parameter is used interactively to configure the UM Router's XML configuration file.-d
or --dump-dtd
. After dumping the DTD, tnwgd exits instead of providing UM Router services as usual. See UM Router Configuration DTD for the DTD with comments removed.-v
or --validate
options. After attempting validation, tnwgd exits instead of providing UM Router services as usual. The exit status will be 0 for a configuration file successfully validated by the DTD, and non-zero otherwise.-s
is used interactively to control the installation of the Windows service. The -e
is used interactively to configure the logging threshold for writing to the Windows Event Log. See UM Daemons as Windows Services for more details.-h
or --help
.
For controlling/configuring each UM Router, you use a XML UM Router configuration file, which also contains references to UM configuration files to extract needed information about the TRDs interfaced by endpoint portals. This chapter includes a lookup reference for the XML UM Router configuration file's elements and DTD.
An XML UM Router configuration file follows standard XML conventions. Element declarations or a pointer to a DTD file are not needed, as these are handled by the UM Router.
An XML UM Router configuration file generally comprises two primary elements: <daemon>
and <portals>
. Organized and contained within these are option value assignments. <daemon>
sub-containers let you set options global to the UM Router. <portals>
sub-containers let you configure each portal in the UM Router individually.
In general, the order of the elements is important. Please refer to the examples and ensure proper element ordering.
XML UM Router configuration files use the high-level structure shown in the following example. This example includes only some container elements, and only some options.
Container for all options residing in the XML UM Router configuration file. This is the top-level element.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
version | The version of the DTD, which is currently. (This is not the product version.) | "1.0" - Current version of DTD. | (no default; must be specified) |
Example:
Container for all endpoint and peer portal configuration information.
Example:
Container element for all configuration options of a single peer portal.
Example:
Configures the rate at which Daemon Statistics messages are published. See Daemon Statistics for general information on Daemon Statistics.
Example:
Configures the rate at which one particular grouping of Daemon Statistics messages are published. See Daemon Statistics for general information on Daemon Statistics.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
name | Name of statistics group being configured. | "default" - Sets a default interval for all message types. "gateway-config" - Sets the interval for messages of type tnwg_dstat_gatewaycfg_msg_t. "route-manager-topology" - Sets the interval for messages of types tnwg_rm_stat_grp_msg_t. "malloc-info" - Sets the interval for messages of type tnwg_dstat_mallinfo_msg_t. "portal-config" - Sets the interval for messages of type tnwg_pcfg_stat_grp_msg_t. "portal-stats" - Sets the interval for messages of type tnwg_dstat_portalstats_msg_t | (no default; must be specified) |
ivl | Time, in seconds, between publishing the statistics group being configured. | string | (no default; must be specified) |
Example:
Contains parameters for the keepalive signals sent from this peer portal. This is a UM Router-level keepalive, not to be confused with the TCP-level <keepalive> element.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
idle | Determines if UM Router keepalives should be sent only if no traffic has been sent or received in the last interval. | "yes" - Send only if no traffic has been exchanged. "no" - Send always, even of traffic has been exchanged. | "yes" |
interval | Minimum interval, in milliseconds, between keepalive messages sent. Informatica recommends setting this to 2000 or greater. A value of 0 (zero) disables keepalives. | string | "5000" |
timeout | Maximum time, in milliseconds, a peer can receive nothing from the companion before determining the connection is dead and disconnecting. We recommend setting this to 3 times the interval value. | string | "15000" |
Example:
Determines timing characteristics for context name queries generated at this portal.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
periodic-interval | Interval (in milliseconds) at which context queries are generated. Before changing the value of this option, please contact Informatica Support. | string | "300000" |
max-contexts | Maximum number of contexts for which queries are generated at one time. Before changing the value of this option, please contact Informatica Support. | string | "20" |
interval | Interval (in milliseconds) between groups of context queries. Before changing the value of this option, please contact Informatica Support. | string | "200" |
timeout | Minimum time (in seconds) a context query must be unanswered before it is removed for the portal. Before changing the value of this option, please contact Informatica Support. | string | "900" |
Example:
Specifies the portal's awareness of received message sequence numbers, for the purpose of detecting duplicates.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
size | Determines the maximum number of topic (fragment) sequence numbers maintained in the window, for any given source. Must be a multiple of 8. Before changing the value of this option, please contact Informatica Support. | string | "16384" |
increment | Determines the minimum increment, in topic (fragment) sequence numbers, by which the sequence number window is moved when the window size (below) is exceeded. Must be a multiple of 8, an even divisor of the window size, and less the window size. Before changing the value of this option, please contact Informatica Support. | string | "2048" |
Example:
Specifies the portal receiver context name.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
xml:space | Specifies how whitespace (tabs, spaces, linefeeds) are handled in the element content. | "default" - Trim leading and trailing whitespace, and compress multiple whitespace characters into a single space. "preserve" - Retain whitespace exactly as entered. | default |
Example:
Specifies the portal source context name.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
xml:space | Specifies how whitespace (tabs, spaces, linefeeds) are handled in the element content. | "default" - Trim leading and trailing whitespace, and compress multiple whitespace characters into a single space. "preserve" - Retain whitespace exactly as entered. | default |
Example:
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
periodic-interval | The interval (in milliseconds) at which source pattern are checked to determine if there is no more interest. This element is deprecated and has no function. | string | "300000" |
Checks for interest in patterns at periodic intervals. This element is deprecated and has no function.
Checks for interest in topics at periodic intervals. This element is deprecated and has no function.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
periodic-interval | The interval (in milliseconds) at which source topics are checked to determine if there is no more interest. This element is deprecated and has no function. | string | "300000" |
Determines how long a domain remains quiescent until it is determined inactive. This element is deprecated and has no function.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
timeout | Minimum time (in seconds) domain interest for a pattern must be refreshed before interest is removed for that domain. This element is deprecated and has no function. | string | "900" |
Determines timing characteristics for interest message generation at this portal. This element is deprecated and has no function.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
periodic-interval | Interval (in milliseconds) at which pattern interest is generated. This element is deprecated and has no function. | string | "300000" |
max-patterns | Maximum patterns for which interest is generated at one time. This element is deprecated and has no function. | string | "300000" |
interval | Interval (in milliseconds) between groups of patterns. This element is deprecated and has no function. | string | "200" |
Determines when this portal's proxy receivers can purge pattern. This element is deprecated and has no function.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
periodic-interval | Interval (in milliseconds) at which receiver patterns are checked to determine if they can be purged. This element is deprecated and has no function. | string | "6000" |
Determines how long a domain remains quiescent until it is determined inactive. This element is deprecated and has no function.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
timeout | Minimum time (in seconds) domain interest for a topic must be refreshed before interest is removed for that domain. This element is deprecated and has no function. | string | "900" |
Determines timing characteristics for interest message generation at this portal. This element is deprecated and has no function.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
periodic-interval | Interval (in milliseconds) at which topic interest is generated. This element is deprecated and has no function. | string | "300000" |
max-topics | Maximum topics for which interest is generated at one time. This element is deprecated and has no function. | string | "20" |
interval | Interval (in milliseconds) between groups of topics. This element is deprecated and has no function. | string | "200" |
Determines when this portal's proxy receivers can purge topics. This element is deprecated and has no function.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
periodic-interval | Interval (in milliseconds) at which receiver topics are checked to determine if they can be purged. This element is deprecated and has no function. | string | "6000" |
Contains elements (inbound and outbound ACEs) that describe how an ACL (Access Control List) filters messages.
Example:
Container for ACE elements, to separate outbound ACEs from inbound ACEs.
Example:
Within an inbound or outbound ACL, you can have one or more "<ace>" elements. Each ACE (Access Control Entry) lets you match and accept or reject messages based on access control condition elements, which are the elements contained within an "<ace>" element.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
match | This required attribute determines what to do with matched messages. | "accept" - Pass the message. "reject" - Block the message. | (no default; must be specified) |
Example:
Defines a condition used in an ACE. Specifically, this is a match pattern for the message's xport ID number. This applies only to LBT-IPC transports.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
value | The xport ID number to be compared. | string | (no default; must be specified) |
comparison | Defines a match condition. | "eq" - Matches if equal. "equal" - Matches if equal. "ne" - Matches if not equal. "notequal" - Matches if not equal. "lt" - Matches if less than. "lessthan" - Matches if less than. "le" - Matches if less than or equal to. "lessthanequal" - Matches if less than or equal to. "gt" - Matches if greater than. "greaterthan" - Matches if greater than. "ge" - Matches if greater than or equal to. "greaterthanequal" - Matches if greater than or equal to. | (no default; must be specified) |
Example:
Defines a condition used in an ACE. Specifically, this is a match pattern for the message's TCP source port number. This applies only to TCP transports.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
value | The xport ID number to be compared. | string | (no default; must be specified) |
comparison | Defines a match condition. | "eq" - Matches if equal. "equal" - Matches if equal. "ne" - Matches if not equal. "notequal" - Matches if not equal. "lt" - Matches if less than. "lessthan" - Matches if less than. "le" - Matches if less than or equal to. "lessthanequal" - Matches if less than or equal to. "gt" - Matches if greater than. "greaterthan" - Matches if greater than. "ge" - Matches if greater than or equal to. "greaterthanequal" - Matches if greater than or equal to. | (no default; must be specified) |
Example:
Defines a condition used in an ACE. Specifically, this is a match pattern for the message's UDP destination port number. This applies only to LBT-RM transports.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
value | The xport ID number to be compared. | string | (no default; must be specified) |
comparison | Defines a match condition. | "eq" - Matches if equal. "equal" - Matches if equal. "ne" - Matches if not equal. "notequal" - Matches if not equal. "lt" - Matches if less than. "lessthan" - Matches if less than. "le" - Matches if less than or equal to. "lessthanequal" - Matches if less than or equal to. "gt" - Matches if greater than. "greaterthan" - Matches if greater than. "ge" - Matches if greater than or equal to. "greaterthanequal" - Matches if greater than or equal to. | (no default; must be specified) |
Example:
Defines a condition used in an ACE. Specifically, this is a match pattern for the message's UDP source port number. This applies only to LBT-RM and LBT-RU transports.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
value | The xport ID number to be compared. | string | (no default; must be specified) |
comparison | Defines a match condition. | "eq" - Matches if equal. "equal" - Matches if equal. "ne" - Matches if not equal. "notequal" - Matches if not equal. "lt" - Matches if less than. "lessthan" - Matches if less than. "le" - Matches if less than or equal to. "lessthanequal" - Matches if less than or equal to. "gt" - Matches if greater than. "greaterthan" - Matches if greater than. "ge" - Matches if greater than or equal to. "greaterthanequal" - Matches if greater than or equal to. | (no default; must be specified) |
Example:
Defines a condition used in an ACE. Specifically, this is a match pattern for the message's multicast group address. This applies only to LBT-RM transports.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
value | The xport ID number to be compared. | string | (no default; must be specified) |
comparison | Defines a match condition. | "eq" - Matches if equal. "equal" - Matches if equal. "ne" - Matches if not equal. "notequal" - Matches if not equal. "lt" - Matches if less than. "lessthan" - Matches if less than. "le" - Matches if less than or equal to. "lessthanequal" - Matches if less than or equal to. "gt" - Matches if greater than. "greaterthan" - Matches if greater than. "ge" - Matches if greater than or equal to. "greaterthanequal" - Matches if greater than or equal to. | (no default; must be specified) |
Example:
Defines a condition used in an ACE. Specifically, this is a match pattern for the message source IP address. This applies only to TCP, LBT-RM, and LBT-RU transports.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
value | The xport ID number to be compared. | string | (no default; must be specified) |
comparison | Defines a match condition. | "eq" - Matches if equal. "equal" - Matches if equal. "ne" - Matches if not equal. "notequal" - Matches if not equal. "lt" - Matches if less than. "lessthan" - Matches if less than. "le" - Matches if less than or equal to. "lessthanequal" - Matches if less than or equal to. "gt" - Matches if greater than. "greaterthan" - Matches if greater than. "ge" - Matches if greater than or equal to. "greaterthanequal" - Matches if greater than or equal to. | (no default; must be specified) |
Example:
Defines a condition used in an ACE. Specifically, this is a match pattern for a UM transport type.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
value | The transport type to be matched. | "tcp" - TCP transport. "lbt-rm" - LBT-RM transport. "lbtrm" - LBT-RM transport. "lbt-ru" - LBT-RU transport. "lbtru" - LBT-RU transport. "lbt-ipc" - IPC transport. "lbtipc" - IPC transport. | (no default; must be specified) |
comparison | Defines a match condition. | "eq" - Matches if equal. "equal" - Matches if equal. "ne" - Matches if not equal. "notequal" - Matches if not equal. | (no default; must be specified) |
Example:
Defines a condition used in an ACE. Specifically, this is a match pattern for a POSIX regular expression matched in the message. This element is deprecated. Please use <pcre-pattern> .
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
xml:space | Specifies how whitespace (tabs, spaces, linefeeds) are handled in the element content. | "default" - Trim leading and trailing whitespace, and compress multiple whitespace characters into a single space. "preserve" - Retain whitespace exactly as entered. | default |
Defines a condition used in an ACE. Specifically, this is a match pattern for a Perl Compatible Regular Expression (PCRE) matched in the message.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
xml:space | Specifies how whitespace (tabs, spaces, linefeeds) are handled in the element content. | "default" - Trim leading and trailing whitespace, and compress multiple whitespace characters into a single space. "preserve" - Retain whitespace exactly as entered. | default |
Example:
Defines a condition used in an ACE. Specifically, this is a match pattern for a topic name.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
xml:space | Specifies how whitespace (tabs, spaces, linefeeds) are handled in the element content. | "default" - Trim leading and trailing whitespace, and compress multiple whitespace characters into a single space. "preserve" - Retain whitespace exactly as entered. | default |
Example:
Container for ACE elements, to separate inbound ACEs from outbound ACEs.
Example:
Container for individual UM-option-setting elements. It lets you set individual UM attributes without referencing a UM configuration file. These values override any values set via files referenced by <lbm-config>.
Example:
Lets you set an individual UM configuration option without referencing a UM configuration file. This value overrides any values set via files referenced by <lbm-config>.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
scope | The type of object to which an option can apply. | "receiver" - Receiver option. "context" - Context option. "source" - Source option. "wildcard_receiver" - Wildcard Receiver option. "event_queue" - Event queue option. | (no default; must be specified) |
name | The name of the option. | attr_name | (no default; must be specified) |
value | The value for the option. | string | (no default; must be specified) |
Example:
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
xml:space | Specifies how whitespace (tabs, spaces, linefeeds) are handled in the element content. | "default" - Trim leading and trailing whitespace, and compress multiple whitespace characters into a single space. "preserve" - Retain whitespace exactly as entered. | default |
Specifies the UM configuration file that contains configuration options associated with this portal.
Example:
Contains batching size and timing parameters for peer link implicit batching. This applies to data messages only: the UM Router sends control messages immediately (flushing any batched data messages). Note: worst-case latency can be dramatically reduced by combining batching with <smart-batch>.
Example:
Specifies the maximum interval (in milliseconds) between when the first message of a batch is queued until the batch is sent. A message stays in the batch queue until this value or <min-length> is met or exceeded (whichever occurs first). If not specified, it defaults to 200 milliseconds. The minimum allowed value is 3 milliseconds.
Example:
Specifies the minimum length of a set of batched messages. When the total length of the batched messages reaches or exceeds this value, the batch is sent. If not specified, it defaults to 8192 bytes.
Example:
Specifies the maximum size a peer portal will allow an outgoing datagram to be before fragmenting it.
Example:
Enables the smart batching algorithm used by the UM Router when forwarding messages from one portal to another. Possible values are 0 (disable) and 1 (enable).
In general, batching algorithms are used to increase throughput, but many such algorithms can produce latency outliers. The Smart Batching algorithm is designed to ensure low latencies by flushing the batching buffer when no more messages are waiting to be sent out the portal.
Smart batching works with both endpoint and peer portals. For endpoint portals, a UM configuration file may be provided to set the implicit_batching_minimum_length (source) option to a large value. For peer portals, the <batching> element may be used to set the <min-length> to a large value. In either case, large values are recommended and will not produce significant latency outliers.
Example:
Sets the maximum buffer size for blocking messages. If not specified, this defaults to 1000000 bytes.
Example:
Sets the time in milliseconds to wait after a route map change occurs before deleting a proxy source. Such a route map change could be due to failure of a UM Router or link within a network.
Example:
Contains elements for a peer portal's tcp settings, when configuring the peer for single-tcp operation.
Example:
Contains the listen port address of the corresponding acceptor peer portal on another UM Router, to which this peer is connected. This element is used in single-tcp peer configurations.
Example:
Contains port number on which an acceptor peer portal listens for connections from the initiating peer portal. The initiating peer portal configuration must specify this port as its initiator port.
Example:
Contains the IP address and the port of the corresponding acceptor peer portal on another UM Router, to which this peer is connected. This element is used in single-tcp peer configurations.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
reconnect-interval | The time interval, in milliseconds, to wait before reconnecting to the companion portal if this connection is interrupted. | string | "5000" |
Example:
Contains the IP port of the acceptor peer portal on another UM Router, to which this initiator peer is connected. (As of UM version 6.10, dual TCP (<tcp>) is no longer supported. Please use <single-tcp> instead.)
Example:
Contains the IP address of the acceptor peer portal on another UM Router, to which this initiator peer is connected via "single TCP". (As of UM version 6.10, dual TCP (<tcp>) is no longer supported. Please use <single-tcp> instead.)
Example:
Contains elements to configure peer link encryption.
Example:
Defines the list of one or more (comma separated) names of cipher suites that are acceptable to this context. The names are in OpenSSL format (the ones with dashes). If more than suite name one is supplied, they should be in descending order of preference. When a remote context negotiates encrypted TCP, the two sides must find a cipher suite in common, otherwise the connection will be canceled.
The default is highly secure and is recommended.
Example:
Specifies the path to a file containing one or more OpenSSL-compatible PEM-formatted TLS client certificates and certificate authorities. If this element is not supplied, the default behavior is to use the system-level trusted certificates and certificate authorities (operating-system dependent). The TLS server uses these trusted certificates to verify the identity of connecting clients. If a client connects and presents a certificate which is not in the server's trusted certificates file, the connection will be canceled.
Example:
Specifies the passphrase needed to decrypt the server private key file specified by <certificate-key>.
Example:
Specifies the path to a file containing the private key associated with the "server" certificate specified by <certificate>. Note that this private key must be protected from intruders. For that reason, when the certificate and private key files are generated, the private key file is typically encrypted with a passphrase. The passphrase is supplied using <certificate-key-password>.
Example:
Specifies the path to a file containing an OpenSSL-compatible PEM-formatted certificate that will be presented as the TLS server certificate when a TLS connection is established by a client.
Example:
Enables compression and sets the desired data compression algorithm for the peer link. Currently, only LZ4 lossless data compression is supported.
Example:
Enables setting the TCP_NODELAY socket option on the peer link. Setting TCP_NODELAY disables Nagle's algorithm, which somewhat decreases the efficiency and throughput of TCP, but decreases the latency of individual messages.
By default, TCP_NODELAY is not set (maximizes efficiency).
Example:
When present, enables a TCP keepalive signal transmission, which is disabled by default.
Example:
Contains the size of the TCP send buffer. If not specified, the UM Router uses the system default size.
Example:
Contains the size of the TCP receive buffer. If not specified, the UM Router uses the system default size.
Example:
Contains the IP host or network address for this peer portal, specified in dotted-decimal or CIDR format.
Example:
DEPRECATED AND ELIMINATED AS OF UM 6.10. DO NOT USE. Contains elements for a peer portal's "dual TCP" settings. (As of UM version 6.10, dual TCP (<tcp>) is no longer supported. Please use <single-tcp> instead.)
DEPRECATED AND ELIMINATED AS OF UM 6.10. DO NOT USE. Contains the IP address and the port of the companion peer portal on another UM Router, to which this peer is connected via "dual TCP". (As of UM version 6.10, dual TCP (<tcp>) is no longer supported. Please use <single-tcp> instead.)
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
reconnect-interval | string |
Sets the size of the peer portal's source map. This normally does not need to be modified, but if very large numbers of topics are being used, a larger value might improve efficiency.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
size | Number of entries in the source map. Value must be a power of 2 (e.g., 1024, 2048, ...). | string | "131072" |
Example:
Assigns a positive non-zero integer cost to the portal. The default value is 1. See Forwarding Costs.
Example:
Lets you set a name for this UM Router (do not duplicate for any other known UM Routers), or for the name of an endpoint or peer portal. Each portal name must be unique within the UM Router.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
xml:space | Specifies how whitespace (tabs, spaces, linefeeds) are handled in the element content. | "default" - Trim leading and trailing whitespace, and compress multiple whitespace characters into a single space. "preserve" - Retain whitespace exactly as entered. | default |
Example:
Container element for all configuration options of a single endpoint portal.
Example:
Determines timings and limits for determination of continued pattern interest at this portal.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
check-interval | Interval (in milliseconds) between checking individual patterns for continued interest. Before changing the value of this option, please contact Informatica Support. | string | "90000" |
max-patterns | Maximum number of patterns to check at a time. Before changing the value of this option, please contact Informatica Support. | string | "100" |
timeout | Minimum time (in milliseconds) remote interest for a pattern must be refreshed before interest is removed for that domain. Before changing the value of this option, please contact Informatica Support. | string | "300000" |
Example:
Determines timings and limits for determination of continued topic interest at this portal.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
check-interval | Interval (in milliseconds) between checking individual topics for continued interest. Before changing the value of this option, please contact Informatica Support. | string | "90000" |
max-topics | Maximum number of topics to check at a time. Before changing the value of this option, please contact Informatica Support. | string | "100" |
timeout | Minimum time (in milliseconds) remote interest for a topic must be refreshed before interest is removed for that domain. Before changing the value of this option, please contact Informatica Support. | string | "300000" |
Example:
DEPRECATED AND ELIMINATED. DO NOT USE. Determines how Late Join is handled by this endpoint portal.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
provide | "source" "always" "never" | ||
forward | "yes" "no" |
Container for UM Router topic resolution behavior options.
Example:
Sets interval and duration for initial topic resolution requests.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
periodic-interval | The interval at which the initial topic resolution requests are sent. Before changing the value of this option, please contact Informatica Support. | string | "1000" |
duration | The minimum duration for which the initial topic resolution requests are sent. Before changing the value of this option, please contact Informatica Support. | string | "10" |
Example:
Sets maximum and minimum limits for the interval between periodic domain route messages being sent for each remote domain that the portal is servicing.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
min-interval | The minimum interval, in milliseconds, between domain route messages being sent for each domain. | string | "100" |
max-interval | The maximum interval, in milliseconds, between domain route messages being sent for each domain. | string | "1000" |
Example:
Sets rate limits for topic resolution data sent over the network.
You can set rate limits individually for each of the topic resolution message types (see children elements).
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
bps | The limit in Bits per Second that data will be sent on the network. A value of 0 disables limiting by bits per second. Before changing the value of this option, please contact Informatica Support. | string | "500000" (For use queries and interest messages) |
objects-per-second | The limit in Objects per Second that data will be sent on the network. A value of 0 disables limiting by objects per second. Before changing the value of this option, please contact Informatica Support. | string | "500" (For use queries) |
Example:
Sets parameters for when and how often this endpoint portal sends pattern interest messages
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
min-interval | The minimum interval, in milliseconds, between pattern interest messages being sent for each pattern the portal has interest in. | string | "1000" |
max-interval | The maximum interval, in milliseconds, between pattern interest messages being sent for each pattern the portal has interest in. | string | "60000" |
Example:
Sets parameters for when and how often this endpoint portal sends topic interest messages.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
min-interval | The minimum interval, in milliseconds, between topic interest messages being sent for each topic the portal has interest in. | string | "1000" |
max-interval | The maximum interval, in milliseconds, between topic interest messages being sent for each topic the portal has interest in. | string | "60000" |
Example:
Sets parameters for when and how often this endpoint portal sends pattern use queries.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
timeout | The maximum time, in milliseconds, to wait for a pattern use response. Before changing the value of this option, please contact Informatica Support. | string | "3000" |
max | Maximum number of pattern use queries to send for a given pattern, each separated by the timeout value before giving up and removing the topic from the topic list. Before changing the value of this option, please contact Informatica Support. | string | "5" |
periodic-interval | The interval, in milliseconds, between periodic pattern use queries being sent for each pattern the portal has interest in. Before changing the value of this option, please contact Informatica Support. | string | "300000" |
Example:
Sets parameters for when and how often this endpoint portal sends topic use queries.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
timeout | The maximum time, in milliseconds, to wait for a topic use response. Before changing the value of this option, please contact Informatica Support. | string | "3000" |
max | Maximum number of topic use queries to send for a given topic, each separated by the timeout value before giving up and removing the topic from the topic list. Before changing the value of this option, please contact Informatica Support. | string | "5" |
periodic-interval | The interval, in milliseconds, between periodic topic use queries being sent for each topic the portal has interest in. Before changing the value of this option, please contact Informatica Support. | string | "300000" |
Example:
Identifies the TRD for this endpoint portal. It must be unique within the UM Router (which means that for any TRD, you can assign only one endpoint portal per UM Router). Also, all endpoints interfacing a given TRD must have the same <domain-id>
value.
Example:
Container for options common to the entire UM Router process.
Example:
Lets you set timing parameters for UM Router rerouting route calculation behavior.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
backoff-interval | How long, in milliseconds, the UM Router waits after the last detected change in topology before initiating a route recalculation. | string | "5000" |
warning-interval | How long, in milliseconds, the UM Router waits before warning that a route recalculation is being held up due to a non-converging topology. | string | "10000" |
Example:
Lets you set control parameters for UM Router initial route setup (or reroute) behavior.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
propagation-interval | The time interval between route information messages that the UM Router sends to other UM Router. | string | "1000" |
check-interval | How often the UM Router checks to see if a route information message needs to be sent, a UM Router has timed out, and/or the routes need to be recalculated. | string | "750" |
timeout | How long a UM Router waits after receiving no route information messages from another UM Router before determining that that UM Router is out of service or unreachable. | string | "4000" |
max-hop-count | The maximum number of UM Routers a route information message can traverse before being discarded. | string | "100" |
Example:
Specifies the UM XML configuration file.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
xml:space | Specifies how whitespace (tabs, spaces, linefeeds) are handled in the element content. | "default" - Trim leading and trailing whitespace, and compress multiple whitespace characters into a single space. "preserve" - Retain whitespace exactly as entered. | default |
Example:
DEPRECATED AND ELIMINATED. DO NOT USE. Specifies the difference between the shortest and longest propagation delays in the network.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
delta | string |
Configures the Daemon Statistics feature. See Daemon Statistics for general information on Daemon Statistics.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
topic | Topic name to use for publishing Daemon Statistics. | string | "tnwgd.monitor" |
Example:
Configures whether the UM Router will respond to monitoring apps requests to change the rate at which Daemon Statistics messages are published. See Daemon Statistics for general information on Daemon Statistics.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
allow | Enable or disable change requests. | "0" - Ignore change requests. "1" - Respond to change requests. | "0" |
Example:
Configures whether the UM Router will respond to monitoring apps requests to send on-demand snapshots of daemon statistics. See Daemon Statistics for general information on Daemon Statistics.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
allow | Enable or disable snapshot requests. | "0" - Ignore snapshot requests. "1" - Respond to snapshot requests. | "0" |
Example:
Identifies the address for the web monitor, in the form of interface:port. You can use "*" to specify the local host.
Omit this element to disable the web monitor.
See Webmon Security for important security information.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
xml:space | Specifies how whitespace (tabs, spaces, linefeeds) are handled in the element content. | "default" - Trim leading and trailing whitespace, and compress multiple whitespace characters into a single space. "preserve" - Retain whitespace exactly as entered. | default |
Example:
Container for UM Transport monitoring configuration elements.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
interval | Monitoring interval, in seconds. 0 disables monitoring. | string | "0" |
Example:
Provides specifics about the monitoring format module.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
module | Selects the message formatting module. | "csv" - Comma-separated values (currently the only supported format). | "csv" |
options | Option string to be passed to the formatting module. Available option is "separator" (defaults to comma). | string | (if omitted, no options are passed to the formatting module) |
Example:
Specifies characteristics about the monitoring transport module used.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
module | Selects the message transport module. | "lbm" - Publish messages via standard UM source. "lbmsnmp" - Publish messages via standard UM source with special settings intended for the UM SNMP agent. "udp" - Publish messages as simple UDP datagrams. | "lbm" |
options | Option string to be passed to the transport module. Available options are "config" (configuration file pathname) and "topic" (the topic name to use for sending and receiving statistics; defaults to "/29west/statistics"). | string | (if omitted, no options are passed to the transport module) |
Example 1:
Example 2:
Monitoring configuration options can be supplied directly in the XML.
Determines characteristics of the internal topic resolution maps for wildcard patterns.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
hash-function | Topic resolution hash function to use. Informatica recommends the default. See resolver_string_hash_function (context) for more information. | "classic" - UM's original hash function. May be better for certain specialized topic names. "djb2" - The Dan Bernstein algorithm from comp.lang.c. May be better for topic names have a changing prefix with a constant suffix. "sdbm" - Sdbm database library (used in Berkeley DB). May be better for certain specialized topic names. "murmur2" - Good all-around hash function by Austin Appleby. | "murmur2" |
size | Number of buckets in hash table. Should be a prime number. | string | "131111" |
Example:
Determines characteristics of the internal topic resolution maps for topic names.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
hash-function | Topic resolution hash function to use. Informatica recommends the default. See resolver_string_hash_function (context) for more information. | "classic" - UM's original hash function. May be better for certain specialized topic names. "djb2" - The Dan Bernstein algorithm from comp.lang.c. May be better for topic names have a changing prefix with a constant suffix. "sdbm" - Sdbm database library (used in Berkeley DB). May be better for certain specialized topic names. "murmur2" - Good all-around hash function by Austin Appleby. | "murmur2" |
size | Number of buckets in hash table. Should be a prime number. | string | "131111" |
Example:
Specifies the UM license file's pathname.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
xml:space | Specifies how whitespace (tabs, spaces, linefeeds) are handled in the element content. | "default" - Trim leading and trailing whitespace, and compress multiple whitespace characters into a single space. "preserve" - Retain whitespace exactly as entered. | default |
Example:
Contains the pathname for daemon process ID (PID) file.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
xml:space | Specifies how whitespace (tabs, spaces, linefeeds) are handled in the element content. | "default" - Trim leading and trailing whitespace, and compress multiple whitespace characters into a single space. "preserve" - Retain whitespace exactly as entered. | default |
Example:
Specifies a Group ID (GID) for daemon process (if run as root).
Example:
Specifies a User ID (UID) for the daemon process (if run as root).
Example:
Specifies the destination for UM Router log messages. If you set the type for "file", use this element to contain the full pathname.
XML Attributes:
Attribute | Description | Valid Values | Default Value |
---|---|---|---|
type | Method of writing logs. | "file" - Write log to disk file. "syslog" - Write log to Unix "syslog". "console" - Write log to standard out. | "console" |
frequency | Frequency by which to roll log file. Only applies for type="file". | "disable" - Do not roll log file. "daily" - Roll log file at midnight. "hourly" - Roll log file after approximately an hour, but is not exact and can drift significantly over a period of time. "test" - For Informatica internal use only. Do not use. | "disable" |
size | Number of millions of bytes of file size to roll log file. E.g. a value of 1 rolls after 1000000 bytes. Maximum value is 4000. Value of 0 disables rolling by file size. Only applies for type="file". | string | "0" |
xml:space | Specifies how whitespace (tabs, spaces, linefeeds) are handled in the element content. | "default" - Trim leading and trailing whitespace, and compress multiple whitespace characters into a single space. "preserve" - Retain whitespace exactly as entered. | default |
Example:
Here is the XML configuration DTD with the comments removed. To see the DTD with comments included, enter tnwgd --dump-dtd
.
This section contains details on the UM Router's Daemon Statistics feature. You should already be familiar with the general information contained in Daemon Statistics.
The different message types are:
Each one has a specific structure associated with it, as detailed in the file tnwgdmonmsgs.h.
Note that message types ending with "CFG" are in the config category. All others are in the stats category. See Daemon Statistics Structures for information on how the two categories are handled differently.
A monitoring application receiving these messages must detect if there is an endian mismatch (see Daemon Statistics Binary Data). The header structure tnwg_dstat_msg_hdr_t contains a 16-bit field named magic
which is set equal to LBM_TNWG_DAEMON_MAGIC. The receiving application should compare it to LBM_TNWG_DAEMON_MAGIC and LBM_TNWG_DAEMON_ANTIMAGIC. Anything else would represent a serious problem.
If the receiving app sees:
then it can simply access the binary fields directly. However, if it sees:
then most (but not all) binary fields need to be byte-swapped. See tnwgdmon.c for an example, paying special attention to the macros COND_SWAPxx
(which conditionally swaps based on the magic test) and the functions byte_swapXX()
(which performs the byte swapping).
UM Router Daemon Statistics data structures sometimes contain string buffers. Strings in these data structures are always null-terminated. These messages are generally sent as fixed-length equal to the sizes of the structures, and therefore include all of the declared bytes of the string fields, even if the contained string uses fewer bytes than declared. For example, the structure tnwg_dstat_record_hdr_t contains the field tnwg_dstat_record_hdr_t_stct::portal_name which is a char
array of size TNWG_DSTAT_MAX_PORTAL_NAME_LEN
. If portal_name
is set to "p1", then only 3 bytes of the buffer are used (including the null string terminator). However, all TNWG_DSTAT_MAX_PORTAL_NAME_LEN
bytes will be sent in the TNWG_DSTATTYPE_RM_PORTAL message type.
Contrast this with Store Daemon Statistics String Buffers.
There are two exceptions to this rule: TNWG_DSTATTYPE_PORTCFG and TNWG_DSTATTYPE_GATEWAYCFG.
The TNWG_DSTATTYPE_PORTCFG message is of type tnwg_pcfg_stat_grp_msg_t and has the field tnwg_pcfg_stat_grp_msg_t_stct::data. This field is a variable-length string buffer which contains one or more null-terminated strings. The total length of the TNWG_DSTATTYPE_PORTCFG message is the sum of the length of its sub-structures plus the number of bytes of string data (characters plus string-terminating nulls). The number of strings in tnwg_pcfg_stat_grp_msg_t_stct::data is given by tnwg_pcfg_stat_grp_msg_t_stct::rechdr->num_options. The monitoring application must step through the string buffer that many times to find each string. For an example of how to do this, see tnwgdmon.c in the code following, "`case TNWG_DSTATTYPE_PORTCFG:`".
The TNWG_DSTATTYPE_GATEWAYCFG message is of type tnwg_dstat_gatewaycfg_msg_t and has the field tnwg_dstat_gatewaycfg_msg_t_stct::data. This field is a variable-length string buffer which contains exactly one null-terminated string. This string contains the entirety of the UM Router's configuration file. The individual lines contain the normal line-ending character(s). The total length of the TNWG_DSTATTYPE_GATEWAYCFG message is the length of its sub-structure plus the number of bytes of string data (characters plus string-terminating nulls).
There are three places in the UM Router configuration file that Daemon Statistics are configured:
Here is an example of configuring daemon statistics.
In this example, all stats-type messages are (conditionally) published on a 3-second interval, except those of portal G1-TRD1, which are published (conditionally) on a 6-second interval. All config-type messages are published (unconditionally) on a 120-second interval.
The UM Router Daemon supports a monitoring application to send a specific set of requests to control the operation of Daemon Statistics. The <remote-snapshot-request> and <remote-config-changes-request> configuration elements control whether the Store enables this request feature (defaults to disabled).
If enabled, the monitoring application can send a command message to the UM Router in the form of a topicless unicast immediate "request" message (see lbm_unicast_immediate_request() with NULL for topic). The format of the message is a simple ascii string, with or without null termination. Due to the simple format of the message, no data structure is defined for it.
When the UM Router receives and validates the command, it sends a UM response message back to the requesting application containing a status message (which is not null-terminated). If the status was OK, the Store also performs the requested action.
The example program tnwgdcmd.c demonstrates the correct way to send the messages and receive the responses.
Commands enabled by <remote-snapshot-request>:
Commands enabled by <remote-config-changes-request>:
mallinfo 5
ri 5
gcfg 5
"G1-TRD1" pstat 5
"G1-TRD1" pcfg 5
The built-in web monitor (configured in the tnwgd XML configuration file; see XML Configuration Reference) provides valuable statistics about the UM Router and its portals, for which, the Web Monitor separates into receive statistics and send statistics. The Web Monitor provides a page for each endpoint and peer portal.
Users are expected to prevent unauthorized access to the web monitor through normal firewalling methods. Users who are unable to limit access to a level consistent with their overall security needs should disable the store web monitor (using <web-monitor>). See Webmon Security for more information.
This page displays general information about the UM Router, and also provides the following links to more detailed statistical and configuration information.
On some platforms, the Main page may include a link (GNU malloc info) to a memory allocation display page that displays the following:
The Endpoint Portal Page displays Receive and Send statistics for the selected endpoint portal. Receive statistics pertain to messages entering the portal from its connected TRD. Send statistics pertain to messages sent out to the TRD.
Click on any of the links at the top of the page to review configuration option values for the portal's UM topic resolution domain. The two columns provide different units of measure for a given statistic type, where the first column is typically in fragments or messages (depending on the statistic type), and the second column is in bytes.
Endpoint Portal name
Endpoint Receive Statistics
Endpoint Send Statistics
This page allows you to see Receive and Send statistics for the selected peer portal. Click on any of the links at the top of the page to review configuration option values for the portal's UM topic resolution domain.
The peer portal page displays the following statistics:
Peer Portal name
Peer Receive Statistics
Immediate topic request fragments/bytes received Of the MIM topic messages received, this is the total of those that are requests.
Peer Send Statistics
Gateway control messages/bytes sent Of the UM Router supervisory messages generated, the number sent to the adjacent UM Router.
Gateway control messages/bytes dropped (blocking) The amount of UM Router supervisory messages that were discarded because they were blocked from sending, probably due to TCP flow control, and were unable to be buffered. The UM Router's XML configuration file may need to be adjusted.
<max-queue>
.
This page allows you to see UM Router network connectivity information from the perspective of this UM Router. The Other UM Routers section (below) provides information in the same format as is used for the local UM Router.
Portal (endpoint or peer)
This display is repeated for each portal of this UM Router.
Other UM Routers
This display is repeated for each other UM Router in this UM Router's network.
The Path Info page lets you query and display a hop path that messages will take between any two TRDs that you enter into the Domain ID 1 and Domain ID 2 text boxes. Fill in the boxes and click the Calculate Shortest Path button, and you see the following fields:
The UM Router daemon generates log messages that are used to monitor its health and operation. You can configure these to be directed to "console" (standard output), "syslog", or a specified log "file", via the <log> configuration element. Normally "console" is only used during testing, as a persistent log file is preferred for production use. The UM Router does not over-write log files on startup, but instead appends them.
To prevent unbounded disk file growth, the UM Router supports rolling log files. When the log file rolls, the file is renamed according to the model:
CONFIGUREDNAME_
PID.
DATE.
SEQNUM
where:
For example: umrouterlog_9867.2017-08-20.2
The user can configure when the log file is eligible to roll over by either or both of two criteria: size and frequency. The size criterion is in millions of bytes. The frequency criterion can be daily or hourly. Once one or both criteria are met, the next message written to the log will trigger a roll operation. These criteria are supplied as attributes to the <log> configuration element.
If both criteria are supplied, then the first one to be reached will trigger a roll. For example, consider the setting:
Let say that the log file grows at 1 million bytes per hour. At 11:00 pm, the log file will reach 23 million bytes, and will roll. Then, at 12:00 midnight, the log file will roll again, even though it is only 1 million bytes in size.
Connection Failure Messages
Lost Connection Messages
Endpoint Messages
If a UMP store is adjacent to the UM Router, and the UM Router has been restarted, you typically see messages of the form:
These messages are normal, and cease when the UM Router has established the forwarding information for the given context.
Peer Messages
Using the <monitor>
element in a UM Router's XML configuration file and the UMS Monitoring feature, you can monitor the transport activity between the UM Router and its Topic Resolution Domain. The configuration also provides Context and Event Queue statistics. The statistics output identifies individual portals by name.
With the release of Ultra Messaging 6.0, the UM Gateway feature is discontinued and replaced by the Ultra Messaging Dynamic Routing Option (also referred to as the UM Router).
The UM Router's primary improvement over the UM Gateway is its ability to intelligently select efficient traffic routes from multiple path choices on a dynamic topic-by-topic basis.
In addition to routing functionality, the following are features of the UM Router that were not provided in the UM Gateway:
<cost>
is 1 (one). 0 (zero) is not a valid cost value. The following configuration options exist in the UM Router but not the UM Gateway. See XML Configuration Reference for more information on these options.
<name>
(as a <daemon>
child) <route-info>
<route-recalculation>
<source-deletion-delay>
<max-queue>
<remote-topic-interest>
<remote-pattern-interest>
<rate-limit>
<domain-route>
<remote-topic>
<remote-pattern>
<sourcemap>
<compression>
<tls>