2 ==================================================================================
3 Copyright (c) 2019 Nokia
4 Copyright (c) 2018-2019 AT&T Intellectual Property.
6 Licensed under the Apache License, Version 2.0 (the "License");
7 you may not use this file except in compliance with the License.
8 You may obtain a copy of the License at
10 http://www.apache.org/licenses/LICENSE-2.0
12 Unless required by applicable law or agreed to in writing, software
13 distributed under the License is distributed on an "AS IS" BASIS,
14 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
15 See the License for the specific language governing permissions and
16 limitations under the License.
17 ==================================================================================
21 Abstract The manual page for the whole RMR library
22 Author E. Scott Daniels
27 .im &{lib}/man/setup.im
33 RMR -- Ric Message Router Library
36 RMR is a library which provides a user application with the ability
37 to send and receive messages to/from other RMR based applications
38 without having to understand the underlying messaging transport environment (e.g., SI95)
39 and without needing to know which other endpoint applications are currently
40 available and accepting messages.
41 To do this, RMR depends on a routing table generated by an external source.
42 This table is used to determine the destination endpoint of each message sent by mapping the
43 message type T (supplied by the user application) to an endpoint entry.
44 Once determined, the message is sent directly to the endpoint.
45 The user application is unaware of which endpoint actually receives the
46 message, and in some cases whether that message was sent to multiple
50 RMR functions do provide for the ability to respond to the specific source
51 instance of a message allowing for either a request response, or call
52 response relationship when needed.
56 The library must be given a route table which maps message types
57 (integers) to endpoint groups such that each time a message of type T
58 is sent, the message is delivered to one member of each group
59 associated with T. For example, message type 2 might route to two
60 different groups where group A has two members, worker1 and worker2,
61 while group B has only one member, logger1.
64 The route table consists of a start record, one or more table entry
65 records, and an end record. All table records contain fields
66 separated with vertical bars (|), and allow for trailing comments with
67 the standard shell comment symbol (hash, #) provided that the start of
68 the comment is separated from the last token on the record by one or
69 more spaces. Leading and trailing white space in each field is
70 ignored. The route table supports two entry types: &ital(rte) and
74 A &ital(rte) entry defines a message type, an optional sender
75 application, and the endpoint(s) which accept the indicated message
76 type. However, this format is deprecated and may be removed in a
77 future version. An example record appears next.
83 The second type of entry is &ital(mse). This entry defines a message
84 type, an optional sender application, a subscription ID, and a
85 collection of endpoints. An example record appears next.
87 mse | 1000,forwarder:43086 | 10 | app2:43086
91 It is the responsibility of the route table generator to know which
92 endpoints belong to which groups, and which groups accept which
93 message types. Once understood, the route table generator publishes a
94 table that is ingested by RMR and used for mapping messages to end
98 The following is a simple route table which causes message types 0
99 through 9 to be routed to specific applications:
104 mse|1|-1|app10:4560,app11:4560
117 The special endpoint "%meid" indicates that the message type (0 in
118 this case) is to be routed to the endpoint which has been listed as
119 the "owner" for the meid appearing in the message. MEID ownership is
120 communicated to RMR using the same Route Table Manager interface and
121 by supplying a "table" such as the one below:
125 mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
126 mme_ar | control2 | meid100 meid101 meid102 meid103
130 This table indicates that the application (endpoint) &ital(control1)
131 "owns" 6 MEIDs and &ital(control2) owns 4. When message type 0 is
132 sent, the MEID in the message will be used to select the endpoint via
136 The MEID table will update the existing owner relationships, and add
137 new ones; it is necessary to send only the changes with the
138 add/replace (mme_ar) entries in the table. When necessary, MEIDs can
139 be deleted by adding an &cw(mme_del) record to the table. The
140 following example illustrates how this might look:
144 mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
145 mme_ar | control2 | meid100 meid101 meid102 meid103
146 mme_del| meid200 meid401
150 &h3(Route Table Syntax)
151 The following illustrates the syntax for both types of route table entries.
156 rte | <message-type>[,<sender-endpoint>] | <round-robin-grp>[;<round-robin-grp>]...
157 mse | <message-type>[,<sender-endpoint>] | <sub-id> | <round-robin-grp>[;<round-robin-grp>]...
162 A round robin group is one or more endpoints from which one will be
163 selected to receive the message. When multiple endpoints are given in
164 a group, they must be separated with a comma. An endpoint is an IP
165 address and port (e.g. 192.158.4.30:8219), or DNS name and port, of
166 the application that should receive the message type. If multiple
167 round-robin groups are given, they must be separated by a semicolon.
170 The MEID map is similar to the route table. Entries are used to add
171 or replace the ownership of one or more MEIDs (mme_ar) or to delete
172 one or more MEIDs (mme_del). The following is the syntax for the MEID
178 mme_ar | <owner-endpoint> | <meid> [<meid>...]
179 mme_del | <meid> [<meid>...]
180 meid_map | end | <count> [| <md5sum>
184 The <count> on the end record indicates the number of mme_ar and mme_del records
185 which were sent; if the count does not match the whole map is refused and dropped.
186 The <owner-endpoint> is the endpoint which should receive the message when a message
187 is routed based on the MEID it contains.
188 A MEID may be "owned" by only one endpoint, and if supplied multiple times, the last
189 observed relationship is used.
190 Each of the lists of MEIDs are blank separated.
193 The optional <md5sum> on the &ital(end) record should be the computed MD5 hash for all
194 records which appear between the start and and records.
195 This allows for a tighter verification that all data was received exactly as the
196 route manager transmitted them.
200 To enable configuration of the library behaviour outside of direct user application
201 control, RMR supports a number of environment variables which provide information
203 The following is a list of the various environment variables, what they control
204 and the defaults which RMR uses if undefined.
207 .** the list of environment vars supported
208 .im &{lib}/man/env_var_list.im
234 rmr_realloc_payload(3),