2 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
3 .. SPDX-License-Identifier: CC-BY-4.0
4 .. CAUTION: this document is generated from source in doc/src/rtd.
5 .. To make changes edit the source and recompile the document.
6 .. Do NOT make changes directly to .rst or .md files.
10 ============================================================================================
14 ============================================================================================
18 --------------------------------------------------------------------------------------------
20 RMr -- Ric Message Router Library
23 --------------------------------------------------------------------------------------------
25 RMr is a library which provides a user application with the
26 ability to send and receive messages to/from other RMr based
27 applications without having to understand the underlying
28 messaging transport environment (e.g. Nanomsg) and without
29 needing to know which other endpoint applications are
30 currently available and accepting messages. To do this, RMr
31 depends on a routing table generated by an external source.
32 This table is used to determine the destination endpoint of
33 each message sent by mapping the message type T (supplied by
34 the user application) to an endpoint entry. Once determined,
35 the message is sent directly to the endpoint. The user
36 application is unaware of which endpoint actually receives
37 the message, and in some cases whether that message was sent
38 to multiple applications.
40 RMr functions do provide for the ability to respond to the
41 specific source instance of a message allowing for either a
42 request response, or call response relationship when needed.
45 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
47 The library must be given a route table which maps message
48 numbers to endpoint groups such that each time a message of
49 type T is sent, the message is delivered to one member of
50 each group associated with T. For example, message type 2
51 might route to two different groups where group A consists of
52 worker1 and worker2, while group B consists only of logger1.
54 It is the responsibility of the route table generator to know
55 which endpoints belong to which groups, and which groups
56 accept which message types. Once understood, the route table
57 generator publishes a table that is ingested by RMr and used
58 for mapping messages to end points.
60 The following is a simple route table which causes message
61 types 0 through 9 to be routed to specific applications:
67 mse|1|-1|app10:4560,app11:4560
80 The special endpoint "%meid" indicates that the message type
81 (0 in this case) is to be routed to the endpoint which has
82 been listed as the "owner" for the meid appearing in the
83 message. MEID ownership is communicated to RMR using the same
84 Route Table Manager interface and by supplying a "table" such
90 mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
91 mme_ar | control2 | meid100 meid101 meid102 meid103
95 This table indicates that the application (endpoint)
96 *control1* "owns" 6 MEIDs and *control2* owns 4. When message
97 type 0 is sent, the MEID in the message will be used to
98 select the endpoint via this table.
100 The MEID table will update the existing owner relationships,
101 and add new ones; it is necessary to send only the changes
102 with the add/replace (mme_ar) entries in the table. When
103 necessary, MEIDs can be deleted by adding an mme_del record
104 to the table. The following example illustrates how this
110 mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
111 mme_ar | control2 | meid100 meid101 meid102 meid103
112 mme_del| meid200 meid401
118 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
120 The following illustrates the syntax for both the route
127 mse | <message-type>[,<sender-endpoint>] | <sub-id> <roud-robin-grp>[;<round-robin-grp>]...
132 A round robin group is one or more endpoints from which one
133 will be selected to receive the message. When multiple
134 endpoints are given in a group, they must be separated with a
135 comma. An endpoint is the IP address and port (e.g.
136 192.158.4.30:8219) or DNS name and port of the application
137 that should receive the message type. If multiple round-robin
138 groups are given, they must be separated by a semicolon, and
141 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
143 The MEID map is similar to the route table. Entries are used
144 to add or replace the ownership of one or more MEIDs (mme_ar)
145 or to delete one or more MEIDs (mme_del). The following is
146 the syntax for the MEID map.
152 mme_ar | <owner-endpoint> | <meid> [<meid>...]
153 mme_del | <meid> [<meid>...]
154 meid_map | end | <count> [| <md5sum>
158 The <count> on the end record indicates the number of mme_ar
159 and mme_del records which were sent; if the count does not
160 match the whole map is refused and dropped. The
161 <owner-endpoint> is the endpoint which should receive the
162 message when a message is routed based on the MEID it
163 contains. A MEID may be "owned" by only one endpoint, and if
164 supplied multiple times, the last observed relationship is
165 used. Each of the lists of MEIDs are blank separated.
167 The optional <md5sum> on the *end* record should be the
168 computed MD5 hash for all records which appear between the
169 start and and records. This allows for a tighter verification
170 that all data was received exactly as the route manager
174 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
176 To enable configuration of the library behaviour outside of
177 direct user application control, RMr supports a number of
178 environment variables which provide information to the
179 library. The following is a list of the various environment
180 variables, what they control and the defaults which RMr uses
187 Allows the async connection mode to be turned off (by
188 setting the value to 0. When set to 1, or missing from the
189 environment, RMR will invoke the connection interface in
190 the transport mechanism using the non-blocking (async)
191 mode. This will likely result in many "soft failures"
192 (retry) until the connection is established, but allows
193 the application to continue unimpeeded should the
194 connection be slow to set up.
199 This provides the interface that RMR will bind listen
200 ports to allowing for a single interface to be used rather
201 than listening across all interfaces. This should be the
202 IP address assigned to the interface that RMR should
203 listen on, and if not defined RMR will listen on all
209 This variable defines the port that RMR should open for
210 communications with Route Manager, and other RMR control
211 applications. If not defined, the port 4561 is assumed.
213 Previously, the RMR_RTG_SVC (route table generator service
214 port) was used to define this port. However, a future
215 version of Route Manager will require RMR to connect and
216 request tables, thus that variable is now used to supply
217 the Route Manager well known address and port.
219 To maintain backwards compatablibility with the older
220 Route Manager versions, the presence of this variable in
221 the environment will shift RMR's behaviour with respect to
222 the default value used when RMR_RTG_SVC is **not**
225 When RMR_CTL_PORT is **defined:** RMR assumes that Route
226 Manager requires RMR to connect and request table updates
227 is made, and the default well known address for Route
228 manager is used (routemgr:4561).
230 When RMR_CTL_PORT is **undefined:** RMR assumes that Route
231 Manager will connect and push table updates, thus the
232 default listen port (4561) is used.
234 To avoid any possible misinterpretation and/or incorrect
235 assumptions on the part of RMR, it is recommended that
236 both the RMR_CTL_PORT and RMR_RTG_SVC be defined. In the
237 case where both variables are defined, RMR will behave
238 exactly as is communicated with the variable's values.
243 The value of this variable depends on the Route Manager in
246 When the Route Manager is expecting to connect to an xAPP
247 and push route tables, this variable must indicate the
248 port which RMR should use to listen for these connections.
250 When the Route Manager is expecting RMR to connect and
251 request a table update during initialisation, the variable
252 should be the host of the Route Manager process.
254 The RMR_CTL_PORT variable (added with the support of
255 sending table update requests to Route manager), controls
256 the behaviour if this variable is not set. See the
257 description of that variable for details.
262 By default RMR writes messages to standard error
263 (incorrectly referred to as log messages) in human
264 readable format. If this environment variable is set to 0,
265 the format of standard error messages might be written in
266 some format not easily read by humans. If missing, a value
272 This is a numeric value which corresponds to the verbosity
273 level used to limit messages written to standard error.
274 The lower the number the less chatty RMR functions are
275 during execution. The following is the current
276 relationship between the value set on this variable and
277 the messages written:
282 Off; no messages of any sort are written.
287 Only critical messages are written (default if this
288 variable does not exist)
293 Errors and all messages written with a lower value.
298 Warnings and all messages written with a lower value.
303 Informational and all messages written with a lower
309 Debugging mode -- all messages written, however this
310 requires RMR to have been compiled with debugging
317 **Deprecated.** Should be set to 1 if the route table
318 generator is sending "plain" messages (not using RMR to
319 send messages, 0 if the rtg is using RMR to send. The
320 default is 1 as we don't expect the rtg to use RMR.
322 This variable is only recognised when using the NNG
323 transport library as it is not possible to support NNG
324 "raw" communications with other transport libraries. It is
325 also necessary to match the value of this variable with
326 the capabilities of the Route Manager; at some point in
327 the future RMR will assume that all Route Manager messages
328 will arrive via an RMR connection and will ignore this
333 This is used to supply a static route table which can be
334 used for debugging, testing, or if no route table
335 generator process is being used to supply the route table.
336 If not defined, no static table is used and RMR will not
337 report *ready* until a table is received. The static route
338 table may contain both the route table (between newrt
339 start and end records), and the MEID map (between meid_map
340 start and end records)
344 This is either the name or IP address which is placed into
345 outbound messages as the message source. This will used
346 when an RMR based application uses the rmr_rts_msg()
347 function to return a response to the sender. If not
348 supplied RMR will use the hostname which in some container
349 environments might not be routable.
351 The value of this variable is also used for Route Manager
352 messages which are sent via an RMR connection.
356 This supplies the name of a verbosity control file. The
357 core RMR functions do not produce messages unless there is
358 a critical failure. However, the route table collection
359 thread, not a part of the main message processing
360 component, can write additional messages to standard
361 error. If this variable is set, RMR will extract the
362 verbosity level for these messages (0 is silent) from the
363 first line of the file. Changes to the file are detected
364 and thus the level can be changed dynamically, however RMR
365 will only suss out this variable during initialisation, so
366 it is impossible to enable verbosity after startup.
370 If set to 1, RMR will write some warnings which are
371 non-performance impacting. If the variable is not defined,
372 or set to 0, RMR will not write these additional warnings.
376 --------------------------------------------------------------------------------------------
378 rmr_alloc_msg(3), rmr_tralloc_msg(3), rmr_call(3),
379 rmr_free_msg(3), rmr_init(3), rmr_init_trace(3),
380 rmr_get_meid(3), rmr_get_src(3), rmr_get_srcip(3),
381 rmr_get_trace(3), rmr_get_trlen(3), rmr_get_xact(3),
382 rmr_payload_size(3), rmr_rcv_msg(3), rmr_rcv_specific(3),
383 rmr_rts_msg(3), rmr_ready(3), rmr_fib(3), rmr_has_str(3),
384 rmr_tokenise(3), rmr_mk_ring(3), rmr_realloc_payload(3),
385 rmr_ring_free(3), rmr_set_trace(3), rmr_torcv_msg(3),
386 rmr_wh_open(3), rmr_wh_send_msg(3)