3 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
4 .. SPDX-License-Identifier: CC-BY-4.0
5 .. CAUTION: this document is generated from source in doc/src/rtd.
6 .. To make changes edit the source and recompile the document.
7 .. Do NOT make changes directly to .rst or .md files.
12 ============================================================================================
16 ============================================================================================
20 --------------------------------------------------------------------------------------------
22 RMR -- Ric Message Router Library
25 --------------------------------------------------------------------------------------------
27 RMR is a library which provides a user application with the
28 ability to send and receive messages to/from other RMR based
29 applications without having to understand the underlying
30 messaging transport environment (e.g., SI95) and without
31 needing to know which other endpoint applications are
32 currently available and accepting messages. To do this, RMR
33 depends on a routing table generated by an external source.
34 This table is used to determine the destination endpoint of
35 each message sent by mapping the message type T (supplied by
36 the user application) to an endpoint entry. Once determined,
37 the message is sent directly to the endpoint. The user
38 application is unaware of which endpoint actually receives
39 the message, and in some cases whether that message was sent
40 to multiple applications.
42 RMR functions do provide for the ability to respond to the
43 specific source instance of a message allowing for either a
44 request response, or call response relationship when needed.
47 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
49 The library must be given a route table which maps message
50 types (integers) to endpoint groups such that each time a
51 message of type T is sent, the message is delivered to one
52 member of each group associated with T. For example, message
53 type 2 might route to two different groups where group A has
54 two members, worker1 and worker2, while group B has only one
57 The route table consists of a start record, one or more table
58 entry records, and an end record. All table records contain
59 fields separated with vertical bars (|), and allow for
60 trailing comments with the standard shell comment symbol
61 (hash, #) provided that the start of the comment is separated
62 from the last token on the record by one or more spaces.
63 Leading and trailing white space in each field is ignored.
64 The route table supports two entry types: *rte* and *mse*.
66 A *rte* entry defines a message type, an optional sender
67 application, and the endpoint(s) which accept the indicated
68 message type. However, this format is deprecated and may be
69 removed in a future version. An example record appears next.
77 The second type of entry is *mse*. This entry defines a
78 message type, an optional sender application, a subscription
79 ID, and a collection of endpoints. An example record appears
84 mse | 1000,forwarder:43086 | 10 | app2:43086
88 It is the responsibility of the route table generator to know
89 which endpoints belong to which groups, and which groups
90 accept which message types. Once understood, the route table
91 generator publishes a table that is ingested by RMR and used
92 for mapping messages to end points.
94 The following is a simple route table which causes message
95 types 0 through 9 to be routed to specific applications:
101 mse|1|-1|app10:4560,app11:4560
114 The special endpoint "%meid" indicates that the message type
115 (0 in this case) is to be routed to the endpoint which has
116 been listed as the "owner" for the meid appearing in the
117 message. MEID ownership is communicated to RMR using the same
118 Route Table Manager interface and by supplying a "table" such
124 mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
125 mme_ar | control2 | meid100 meid101 meid102 meid103
129 This table indicates that the application (endpoint)
130 *control1* "owns" 6 MEIDs and *control2* owns 4. When message
131 type 0 is sent, the MEID in the message will be used to
132 select the endpoint via this table.
134 The MEID table will update the existing owner relationships,
135 and add new ones; it is necessary to send only the changes
136 with the add/replace (mme_ar) entries in the table. When
137 necessary, MEIDs can be deleted by adding an mme_del record
138 to the table. The following example illustrates how this
144 mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
145 mme_ar | control2 | meid100 meid101 meid102 meid103
146 mme_del| meid200 meid401
152 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
154 The following illustrates the syntax for both types of route
161 rte | <message-type>[,<sender-endpoint>] | <round-robin-grp>[;<round-robin-grp>]...
162 mse | <message-type>[,<sender-endpoint>] | <sub-id> | <round-robin-grp>[;<round-robin-grp>]...
167 A round robin group is one or more endpoints from which one
168 will be selected to receive the message. When multiple
169 endpoints are given in a group, they must be separated with a
170 comma. An endpoint is an IP address and port (e.g.
171 192.158.4.30:8219), or DNS name and port, of the application
172 that should receive the message type. If multiple round-robin
173 groups are given, they must be separated by a semicolon.
176 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
178 The MEID map is similar to the route table. Entries are used
179 to add or replace the ownership of one or more MEIDs (mme_ar)
180 or to delete one or more MEIDs (mme_del). The following is
181 the syntax for the MEID map.
187 mme_ar | <owner-endpoint> | <meid> [<meid>...]
188 mme_del | <meid> [<meid>...]
189 meid_map | end | <count> [| <md5sum>
193 The <count> on the end record indicates the number of mme_ar
194 and mme_del records which were sent; if the count does not
195 match the whole map is refused and dropped. The
196 <owner-endpoint> is the endpoint which should receive the
197 message when a message is routed based on the MEID it
198 contains. A MEID may be "owned" by only one endpoint, and if
199 supplied multiple times, the last observed relationship is
200 used. Each of the lists of MEIDs are blank separated.
202 The optional <md5sum> on the *end* record should be the
203 computed MD5 hash for all records which appear between the
204 start and and records. This allows for a tighter verification
205 that all data was received exactly as the route manager
209 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
211 To enable configuration of the library behaviour outside of
212 direct user application control, RMR supports a number of
213 environment variables which provide information to the
214 library. The following is a list of the various environment
215 variables, what they control and the defaults which RMR uses
222 Allows the async connection mode to be turned off (by
223 setting the value to 0). When set to 1, or missing from
224 the environment, RMR will invoke the connection interface
225 in the transport mechanism using the non-blocking (async)
226 mode. This will likely result in many "soft failures"
227 (retry) until the connection is established, but allows
228 the application to continue unimpeded should the
229 connection be slow to set up.
234 This provides the interface that RMR will bind listen
235 ports to, allowing for a single interface to be used
236 rather than listening across all interfaces. This should
237 be the IP address assigned to the interface that RMR
238 should listen on, and if not defined RMR will listen on
244 This variable defines the port that RMR should open for
245 communications with Route Manager, and other RMR control
246 applications. If not defined, the port 4561 is assumed.
248 Previously, the RMR_RTG_SVC (route table generator service
249 port) was used to define this port. However, a future
250 version of Route Manager will require RMR to connect and
251 request tables, thus that variable is now used to supply
252 the Route Manager's well-known address and port.
254 To maintain backwards compatibility with the older Route
255 Manager versions, the presence of this variable in the
256 environment will shift RMR's behaviour with respect to the
257 default value used when RMR_RTG_SVC is **not** defined.
259 When RMR_CTL_PORT is **defined:** RMR assumes that Route
260 Manager requires RMR to connect and request table updates
261 is made, and the default well-known address for Route
262 manager is used (routemgr:4561).
264 When RMR_CTL_PORT is **undefined:** RMR assumes that Route
265 Manager will connect and push table updates, thus the
266 default listen port (4561) is used.
268 To avoid any possible misinterpretation and/or incorrect
269 assumptions on the part of RMR, it is recommended that
270 both the RMR_CTL_PORT and RMR_RTG_SVC be defined. In the
271 case where both variables are defined, RMR will behave
272 exactly as is communicated with the variable's values.
277 The value of this variable depends on the Route Manager in
280 When the Route Manager is expecting to connect to an xAPP
281 and push route tables, this variable must indicate the
282 port which RMR should use to listen for these connections.
284 When the Route Manager is expecting RMR to connect and
285 request a table update during initialisation, the variable
286 should be the host of the Route Manager process.
288 The RMR_CTL_PORT variable (added with the support of
289 sending table update requests to Route manager), controls
290 the behaviour if this variable is not set. See the
291 description of that variable for details.
296 By default RMR writes messages to standard error
297 (incorrectly referred to as log messages) in human
298 readable format. If this environment variable is set to 0,
299 the format of standard error messages might be written in
300 some format not easily read by humans. If missing, a value
306 This is a numeric value which corresponds to the verbosity
307 level used to limit messages written to standard error.
308 The lower the number the less chatty RMR functions are
309 during execution. The following is the current
310 relationship between the value set on this variable and
311 the messages written:
316 Off; no messages of any sort are written.
321 Only critical messages are written (default if this
322 variable does not exist)
327 Errors and all messages written with a lower value.
332 Warnings and all messages written with a lower value.
337 Informational and all messages written with a lower
343 Debugging mode -- all messages written, however this
344 requires RMR to have been compiled with debugging
351 **Deprecated.** Should be set to 1 if the route table
352 generator is sending "plain" messages (not using RMR to
353 send messages), 0 if the RTG is using RMR to send. The
354 default is 1 as we don't expect the RTG to use RMR.
356 This variable is only recognised when using the NNG
357 transport library as it is not possible to support NNG
358 "raw" communications with other transport libraries. It is
359 also necessary to match the value of this variable with
360 the capabilities of the Route Manager; at some point in
361 the future RMR will assume that all Route Manager messages
362 will arrive via an RMR connection and will ignore this
367 This is used to supply a static route table which can be
368 used for debugging, testing, or if no route table
369 generator process is being used to supply the route table.
370 If not defined, no static table is used and RMR will not
371 report *ready* until a table is received. The static route
372 table may contain both the route table (between newrt
373 start and end records), and the MEID map (between meid_map
374 start and end records).
378 This is either the name or IP address which is placed into
379 outbound messages as the message source. This will used
380 when an RMR based application uses the rmr_rts_msg()
381 function to return a response to the sender. If not
382 supplied RMR will use the hostname which in some container
383 environments might not be routable.
385 The value of this variable is also used for Route Manager
386 messages which are sent via an RMR connection.
390 This supplies the name of a verbosity control file. The
391 core RMR functions do not produce messages unless there is
392 a critical failure. However, the route table collection
393 thread, not a part of the main message processing
394 component, can write additional messages to standard
395 error. If this variable is set, RMR will extract the
396 verbosity level for these messages (0 is silent) from the
397 first line of the file. Changes to the file are detected
398 and thus the level can be changed dynamically, however RMR
399 will only suss out this variable during initialisation, so
400 it is impossible to enable verbosity after startup.
404 If set to 1, RMR will write some warnings which are
405 non-performance impacting. If the variable is not defined,
406 or set to 0, RMR will not write these additional warnings.
410 --------------------------------------------------------------------------------------------
412 rmr_alloc_msg(3), rmr_tralloc_msg(3), rmr_call(3),
413 rmr_free_msg(3), rmr_init(3), rmr_init_trace(3),
414 rmr_get_meid(3), rmr_get_src(3), rmr_get_srcip(3),
415 rmr_get_trace(3), rmr_get_trlen(3), rmr_get_xact(3),
416 rmr_payload_size(3), rmr_rcv_msg(3), rmr_rcv_specific(3),
417 rmr_rts_msg(3), rmr_ready(3), rmr_fib(3), rmr_has_str(3),
418 rmr_tokenise(3), rmr_mk_ring(3), rmr_realloc_payload(3),
419 rmr_ring_free(3), rmr_set_trace(3), rmr_torcv_msg(3),
420 rmr_wh_open(3), rmr_wh_send_msg(3)