docs/overview.rst

   1
   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.
   7
   8
   9 RMR Overview
  10 ============================================================================================
  11
  12
  13 RMr Library
  14 ============================================================================================
  15
  16
  17 NAME
  18 --------------------------------------------------------------------------------------------
  19
  20 RMr -- Ric Message Router Library
  21
  22 DESCRIPTION
  23 --------------------------------------------------------------------------------------------
  24
  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., SI95) 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.
  39
  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.
  43
  44 The Route Table
  45 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  46
  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.
  53
  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.
  59
  60 The following is a simple route table which causes message
  61 types 0 through 9 to be routed to specific applications:
  62
  63 ::
  64
  65  newrt|start
  66     mse|0|-1| %meid
  67     mse|1|-1|app10:4560,app11:4560
  68     mse|2|-1|app12:4560
  69     mse|3|-1|app14:4560
  70     mse|4|-1|app18:4560
  71     mse|5|-1|app01:4560
  72     mse|6|-1|app02:4560
  73     mse|7|-1|app03:4560
  74     mse|8|-1|app04:4560
  75     mse|9|-1|app05:4560
  76  newrt|end
  77
  78
  79
  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
  85 as the one below:
  86
  87 ::
  88
  89  meid_map | start
  90     mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
  91     mme_ar | control2 | meid100 meid101 meid102 meid103
  92  meid_map | end | 2
  93
  94
  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.
  99
 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
 105 might look:
 106
 107 ::
 108
 109  meid_map | start
 110     mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
 111     mme_ar | control2 | meid100 meid101 meid102 meid103
 112     mme_del| meid200 meid401
 113  meid_map | end | 3
 114
 115
 116
 117 Route Table Syntax
 118 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 119
 120 The following illustrates the syntax for both the route
 121 table.
 122
 123
 124 ::
 125
 126  newrt | start
 127  mse | <message-type>[,<sender-endpoint>] | <sub-id> <roud-robin-grp>[;<round-robin-grp>]...
 128  newrt | end
 129
 130
 131
 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
 139
 140 MEID Map Syntax
 141 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 142
 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.
 147
 148
 149 ::
 150
 151  meid_map | start
 152  mme_ar | <owner-endpoint> | <meid> [<meid>...]
 153  mme_del | <meid> [<meid>...]
 154  meid_map | end | <count> [| <md5sum>
 155
 156
 157
 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.
 166
 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
 171 transmitted them.
 172
 173 Environment
 174 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 175
 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
 181 if undefined.
 182
 183
 184
 185 RMR_ASYNC_CONN
 186
 187   Allows the async connection mode to be turned off (by
 188   setting the value to 0). When set to 1, or missing from
 189   the environment, RMR will invoke the connection interface
 190   in 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 unimpeded should the
 194   connection be slow to set up.
 195
 196
 197 RMR_BIND_IF
 198
 199   This provides the interface that RMR will bind listen
 200   ports to, allowing for a single interface to be used
 201   rather than listening across all interfaces. This should
 202   be the IP address assigned to the interface that RMR
 203   should listen on, and if not defined RMR will listen on
 204   all interfaces.
 205
 206
 207 RMR_CTL_PORT
 208
 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.
 212
 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's well-known address and port.
 218
 219   To maintain backwards compatibility with the older Route
 220   Manager versions, the presence of this variable in the
 221   environment will shift RMR's behaviour with respect to the
 222   default value used when RMR_RTG_SVC is **not** defined.
 223
 224   When RMR_CTL_PORT is **defined:** RMR assumes that Route
 225   Manager requires RMR to connect and request table updates
 226   is made, and the default well-known address for Route
 227   manager is used (routemgr:4561).
 228
 229   When RMR_CTL_PORT is **undefined:** RMR assumes that Route
 230   Manager will connect and push table updates, thus the
 231   default listen port (4561) is used.
 232
 233   To avoid any possible misinterpretation and/or incorrect
 234   assumptions on the part of RMR, it is recommended that
 235   both the RMR_CTL_PORT and RMR_RTG_SVC be defined. In the
 236   case where both variables are defined, RMR will behave
 237   exactly as is communicated with the variable's values.
 238
 239
 240 RMR_RTG_SVC
 241
 242   The value of this variable depends on the Route Manager in
 243   use.
 244
 245   When the Route Manager is expecting to connect to an xAPP
 246   and push route tables, this variable must indicate the
 247   port which RMR should use to listen for these connections.
 248
 249   When the Route Manager is expecting RMR to connect and
 250   request a table update during initialisation, the variable
 251   should be the host of the Route Manager process.
 252
 253   The RMR_CTL_PORT variable (added with the support of
 254   sending table update requests to Route manager), controls
 255   the behaviour if this variable is not set. See the
 256   description of that variable for details.
 257
 258
 259 RMR_HR_LOG
 260
 261   By default RMR writes messages to standard error
 262   (incorrectly referred to as log messages) in human
 263   readable format. If this environment variable is set to 0,
 264   the format of standard error messages might be written in
 265   some format not easily read by humans. If missing, a value
 266   of 1 is assumed.
 267
 268
 269 RMR_LOG_VLEVEL
 270
 271   This is a numeric value which corresponds to the verbosity
 272   level used to limit messages written to standard error.
 273   The lower the number the less chatty RMR functions are
 274   during execution. The following is the current
 275   relationship between the value set on this variable and
 276   the messages written:
 277
 278
 279 0
 280
 281   Off; no messages of any sort are written.
 282
 283
 284 1
 285
 286   Only critical messages are written (default if this
 287   variable does not exist)
 288
 289
 290 2
 291
 292   Errors and all messages written with a lower value.
 293
 294
 295 3
 296
 297   Warnings and all messages written with a lower value.
 298
 299
 300 4
 301
 302   Informational and all messages written with a lower
 303   value.
 304
 305
 306 5
 307
 308   Debugging mode -- all messages written, however this
 309   requires RMR to have been compiled with debugging
 310   support enabled.
 311
 312
 313
 314 RMR_RTG_ISRAW
 315
 316   **Deprecated.** Should be set to 1 if the route table
 317   generator is sending "plain" messages (not using RMR to
 318   send messages), 0 if the RTG is using RMR to send. The
 319   default is 1 as we don't expect the RTG to use RMR.
 320
 321   This variable is only recognised when using the NNG
 322   transport library as it is not possible to support NNG
 323   "raw" communications with other transport libraries. It is
 324   also necessary to match the value of this variable with
 325   the capabilities of the Route Manager; at some point in
 326   the future RMR will assume that all Route Manager messages
 327   will arrive via an RMR connection and will ignore this
 328   variable.
 329
 330 RMR_SEED_RT
 331
 332   This is used to supply a static route table which can be
 333   used for debugging, testing, or if no route table
 334   generator process is being used to supply the route table.
 335   If not defined, no static table is used and RMR will not
 336   report *ready* until a table is received. The static route
 337   table may contain both the route table (between newrt
 338   start and end records), and the MEID map (between meid_map
 339   start and end records).
 340
 341 RMR_SRC_ID
 342
 343   This is either the name or IP address which is placed into
 344   outbound messages as the message source. This will used
 345   when an RMR based application uses the rmr_rts_msg()
 346   function to return a response to the sender. If not
 347   supplied RMR will use the hostname which in some container
 348   environments might not be routable.
 349
 350   The value of this variable is also used for Route Manager
 351   messages which are sent via an RMR connection.
 352
 353 RMR_VCTL_FILE
 354
 355   This supplies the name of a verbosity control file. The
 356   core RMR functions do not produce messages unless there is
 357   a critical failure. However, the route table collection
 358   thread, not a part of the main message processing
 359   component, can write additional messages to standard
 360   error. If this variable is set, RMR will extract the
 361   verbosity level for these messages (0 is silent) from the
 362   first line of the file. Changes to the file are detected
 363   and thus the level can be changed dynamically, however RMR
 364   will only suss out this variable during initialisation, so
 365   it is impossible to enable verbosity after startup.
 366
 367 RMR_WARNINGS
 368
 369   If set to 1, RMR will write some warnings which are
 370   non-performance impacting. If the variable is not defined,
 371   or set to 0, RMR will not write these additional warnings.
 372
 373
 374 SEE ALSO
 375 --------------------------------------------------------------------------------------------
 376
 377 rmr_alloc_msg(3), rmr_tralloc_msg(3), rmr_call(3),
 378 rmr_free_msg(3), rmr_init(3), rmr_init_trace(3),
 379 rmr_get_meid(3), rmr_get_src(3), rmr_get_srcip(3),
 380 rmr_get_trace(3), rmr_get_trlen(3), rmr_get_xact(3),
 381 rmr_payload_size(3), rmr_rcv_msg(3), rmr_rcv_specific(3),
 382 rmr_rts_msg(3), rmr_ready(3), rmr_fib(3), rmr_has_str(3),
 383 rmr_tokenise(3), rmr_mk_ring(3), rmr_realloc_payload(3),
 384 rmr_ring_free(3), rmr_set_trace(3), rmr_torcv_msg(3),
 385 rmr_wh_open(3), rmr_wh_send_msg(3)