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 numbers to endpoint groups such that each time a message of
51 type T is sent, the message is delivered to one member of
52 each group associated with T. For example, message type 2
53 might route to two different groups where group A consists of
54 worker1 and worker2, while group B consists only of logger1.
56 It is the responsibility of the route table generator to know
57 which endpoints belong to which groups, and which groups
58 accept which message types. Once understood, the route table
59 generator publishes a table that is ingested by RMR and used
60 for mapping messages to end points.
62 The following is a simple route table which causes message
63 types 0 through 9 to be routed to specific applications:
69 mse|1|-1|app10:4560,app11:4560
82 The special endpoint "%meid" indicates that the message type
83 (0 in this case) is to be routed to the endpoint which has
84 been listed as the "owner" for the meid appearing in the
85 message. MEID ownership is communicated to RMR using the same
86 Route Table Manager interface and by supplying a "table" such
92 mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
93 mme_ar | control2 | meid100 meid101 meid102 meid103
97 This table indicates that the application (endpoint)
98 *control1* "owns" 6 MEIDs and *control2* owns 4. When message
99 type 0 is sent, the MEID in the message will be used to
100 select the endpoint via this table.
102 The MEID table will update the existing owner relationships,
103 and add new ones; it is necessary to send only the changes
104 with the add/replace (mme_ar) entries in the table. When
105 necessary, MEIDs can be deleted by adding an mme_del record
106 to the table. The following example illustrates how this
112 mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
113 mme_ar | control2 | meid100 meid101 meid102 meid103
114 mme_del| meid200 meid401
120 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
122 The following illustrates the syntax for both the route
129 mse | <message-type>[,<sender-endpoint>] | <sub-id> | <round-robin-grp>[;<round-robin-grp>]...
134 A round robin group is one or more endpoints from which one
135 will be selected to receive the message. When multiple
136 endpoints are given in a group, they must be separated with a
137 comma. An endpoint is the IP address and port (e.g.
138 192.158.4.30:8219) or DNS name and port of the application
139 that should receive the message type. If multiple round-robin
140 groups are given, they must be separated by a semicolon, and
143 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
145 The MEID map is similar to the route table. Entries are used
146 to add or replace the ownership of one or more MEIDs (mme_ar)
147 or to delete one or more MEIDs (mme_del). The following is
148 the syntax for the MEID map.
154 mme_ar | <owner-endpoint> | <meid> [<meid>...]
155 mme_del | <meid> [<meid>...]
156 meid_map | end | <count> [| <md5sum>
160 The <count> on the end record indicates the number of mme_ar
161 and mme_del records which were sent; if the count does not
162 match the whole map is refused and dropped. The
163 <owner-endpoint> is the endpoint which should receive the
164 message when a message is routed based on the MEID it
165 contains. A MEID may be "owned" by only one endpoint, and if
166 supplied multiple times, the last observed relationship is
167 used. Each of the lists of MEIDs are blank separated.
169 The optional <md5sum> on the *end* record should be the
170 computed MD5 hash for all records which appear between the
171 start and and records. This allows for a tighter verification
172 that all data was received exactly as the route manager
176 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
178 To enable configuration of the library behaviour outside of
179 direct user application control, RMR supports a number of
180 environment variables which provide information to the
181 library. The following is a list of the various environment
182 variables, what they control and the defaults which RMR uses
189 Allows the async connection mode to be turned off (by
190 setting the value to 0). When set to 1, or missing from
191 the environment, RMR will invoke the connection interface
192 in the transport mechanism using the non-blocking (async)
193 mode. This will likely result in many "soft failures"
194 (retry) until the connection is established, but allows
195 the application to continue unimpeded should the
196 connection be slow to set up.
201 This provides the interface that RMR will bind listen
202 ports to, allowing for a single interface to be used
203 rather than listening across all interfaces. This should
204 be the IP address assigned to the interface that RMR
205 should listen on, and if not defined RMR will listen on
211 This variable defines the port that RMR should open for
212 communications with Route Manager, and other RMR control
213 applications. If not defined, the port 4561 is assumed.
215 Previously, the RMR_RTG_SVC (route table generator service
216 port) was used to define this port. However, a future
217 version of Route Manager will require RMR to connect and
218 request tables, thus that variable is now used to supply
219 the Route Manager's well-known address and port.
221 To maintain backwards compatibility with the older Route
222 Manager versions, the presence of this variable in the
223 environment will shift RMR's behaviour with respect to the
224 default value used when RMR_RTG_SVC is **not** defined.
226 When RMR_CTL_PORT is **defined:** RMR assumes that Route
227 Manager requires RMR to connect and request table updates
228 is made, and the default well-known address for Route
229 manager is used (routemgr:4561).
231 When RMR_CTL_PORT is **undefined:** RMR assumes that Route
232 Manager will connect and push table updates, thus the
233 default listen port (4561) is used.
235 To avoid any possible misinterpretation and/or incorrect
236 assumptions on the part of RMR, it is recommended that
237 both the RMR_CTL_PORT and RMR_RTG_SVC be defined. In the
238 case where both variables are defined, RMR will behave
239 exactly as is communicated with the variable's values.
244 The value of this variable depends on the Route Manager in
247 When the Route Manager is expecting to connect to an xAPP
248 and push route tables, this variable must indicate the
249 port which RMR should use to listen for these connections.
251 When the Route Manager is expecting RMR to connect and
252 request a table update during initialisation, the variable
253 should be the host of the Route Manager process.
255 The RMR_CTL_PORT variable (added with the support of
256 sending table update requests to Route manager), controls
257 the behaviour if this variable is not set. See the
258 description of that variable for details.
263 By default RMR writes messages to standard error
264 (incorrectly referred to as log messages) in human
265 readable format. If this environment variable is set to 0,
266 the format of standard error messages might be written in
267 some format not easily read by humans. If missing, a value
273 This is a numeric value which corresponds to the verbosity
274 level used to limit messages written to standard error.
275 The lower the number the less chatty RMR functions are
276 during execution. The following is the current
277 relationship between the value set on this variable and
278 the messages written:
283 Off; no messages of any sort are written.
288 Only critical messages are written (default if this
289 variable does not exist)
294 Errors and all messages written with a lower value.
299 Warnings and all messages written with a lower value.
304 Informational and all messages written with a lower
310 Debugging mode -- all messages written, however this
311 requires RMR to have been compiled with debugging
318 **Deprecated.** Should be set to 1 if the route table
319 generator is sending "plain" messages (not using RMR to
320 send messages), 0 if the RTG is using RMR to send. The
321 default is 1 as we don't expect the RTG to use RMR.
323 This variable is only recognised when using the NNG
324 transport library as it is not possible to support NNG
325 "raw" communications with other transport libraries. It is
326 also necessary to match the value of this variable with
327 the capabilities of the Route Manager; at some point in
328 the future RMR will assume that all Route Manager messages
329 will arrive via an RMR connection and will ignore this
334 This is used to supply a static route table which can be
335 used for debugging, testing, or if no route table
336 generator process is being used to supply the route table.
337 If not defined, no static table is used and RMR will not
338 report *ready* until a table is received. The static route
339 table may contain both the route table (between newrt
340 start and end records), and the MEID map (between meid_map
341 start and end records).
345 This is either the name or IP address which is placed into
346 outbound messages as the message source. This will used
347 when an RMR based application uses the rmr_rts_msg()
348 function to return a response to the sender. If not
349 supplied RMR will use the hostname which in some container
350 environments might not be routable.
352 The value of this variable is also used for Route Manager
353 messages which are sent via an RMR connection.
357 This supplies the name of a verbosity control file. The
358 core RMR functions do not produce messages unless there is
359 a critical failure. However, the route table collection
360 thread, not a part of the main message processing
361 component, can write additional messages to standard
362 error. If this variable is set, RMR will extract the
363 verbosity level for these messages (0 is silent) from the
364 first line of the file. Changes to the file are detected
365 and thus the level can be changed dynamically, however RMR
366 will only suss out this variable during initialisation, so
367 it is impossible to enable verbosity after startup.
371 If set to 1, RMR will write some warnings which are
372 non-performance impacting. If the variable is not defined,
373 or set to 0, RMR will not write these additional warnings.
377 --------------------------------------------------------------------------------------------
379 rmr_alloc_msg(3), rmr_tralloc_msg(3), rmr_call(3),
380 rmr_free_msg(3), rmr_init(3), rmr_init_trace(3),
381 rmr_get_meid(3), rmr_get_src(3), rmr_get_srcip(3),
382 rmr_get_trace(3), rmr_get_trlen(3), rmr_get_xact(3),
383 rmr_payload_size(3), rmr_rcv_msg(3), rmr_rcv_specific(3),
384 rmr_rts_msg(3), rmr_ready(3), rmr_fib(3), rmr_has_str(3),
385 rmr_tokenise(3), rmr_mk_ring(3), rmr_realloc_payload(3),
386 rmr_ring_free(3), rmr_set_trace(3), rmr_torcv_msg(3),
387 rmr_wh_open(3), rmr_wh_send_msg(3)