docs/overview.rst

   1
   2
   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.
   8
   9
  10
  11 RMR Overview
  12 ============================================================================================
  13
  14
  15 RMR Library
  16 ============================================================================================
  17
  18
  19 NAME
  20 --------------------------------------------------------------------------------------------
  21
  22 RMR -- Ric Message Router Library
  23
  24 DESCRIPTION
  25 --------------------------------------------------------------------------------------------
  26
  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.
  41
  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.
  45
  46 The Route Table
  47 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  48
  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.
  55
  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.
  61
  62 The following is a simple route table which causes message
  63 types 0 through 9 to be routed to specific applications:
  64
  65 ::
  66
  67  newrt|start
  68     mse|0|-1| %meid
  69     mse|1|-1|app10:4560,app11:4560
  70     mse|2|-1|app12:4560
  71     mse|3|-1|app14:4560
  72     mse|4|-1|app18:4560
  73     mse|5|-1|app01:4560
  74     mse|6|-1|app02:4560
  75     mse|7|-1|app03:4560
  76     mse|8|-1|app04:4560
  77     mse|9|-1|app05:4560
  78  newrt|end
  79
  80
  81
  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
  87 as the one below:
  88
  89 ::
  90
  91  meid_map | start
  92     mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
  93     mme_ar | control2 | meid100 meid101 meid102 meid103
  94  meid_map | end | 2
  95
  96
  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.
 101
 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
 107 might look:
 108
 109 ::
 110
 111  meid_map | start
 112     mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
 113     mme_ar | control2 | meid100 meid101 meid102 meid103
 114     mme_del| meid200 meid401
 115  meid_map | end | 3
 116
 117
 118
 119 Route Table Syntax
 120 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 121
 122 The following illustrates the syntax for both the route
 123 table.
 124
 125
 126 ::
 127
 128  newrt | start
 129  mse | <message-type>[,<sender-endpoint>] | <sub-id> <roud-robin-grp>[;<round-robin-grp>]...
 130  newrt | end
 131
 132
 133
 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
 141
 142 MEID Map Syntax
 143 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 144
 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.
 149
 150
 151 ::
 152
 153  meid_map | start
 154  mme_ar | <owner-endpoint> | <meid> [<meid>...]
 155  mme_del | <meid> [<meid>...]
 156  meid_map | end | <count> [| <md5sum>
 157
 158
 159
 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.
 168
 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
 173 transmitted them.
 174
 175 Environment
 176 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 177
 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
 183 if undefined.
 184
 185
 186
 187 RMR_ASYNC_CONN
 188
 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.
 197
 198
 199 RMR_BIND_IF
 200
 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
 206   all interfaces.
 207
 208
 209 RMR_CTL_PORT
 210
 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.
 214
 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.
 220
 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.
 225
 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).
 230
 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.
 234
 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.
 240
 241
 242 RMR_RTG_SVC
 243
 244   The value of this variable depends on the Route Manager in
 245   use.
 246
 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.
 250
 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.
 254
 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.
 259
 260
 261 RMR_HR_LOG
 262
 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
 268   of 1 is assumed.
 269
 270
 271 RMR_LOG_VLEVEL
 272
 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:
 279
 280
 281 0
 282
 283   Off; no messages of any sort are written.
 284
 285
 286 1
 287
 288   Only critical messages are written (default if this
 289   variable does not exist)
 290
 291
 292 2
 293
 294   Errors and all messages written with a lower value.
 295
 296
 297 3
 298
 299   Warnings and all messages written with a lower value.
 300
 301
 302 4
 303
 304   Informational and all messages written with a lower
 305   value.
 306
 307
 308 5
 309
 310   Debugging mode -- all messages written, however this
 311   requires RMR to have been compiled with debugging
 312   support enabled.
 313
 314
 315
 316 RMR_RTG_ISRAW
 317
 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.
 322
 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
 330   variable.
 331
 332 RMR_SEED_RT
 333
 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).
 342
 343 RMR_SRC_ID
 344
 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.
 351
 352   The value of this variable is also used for Route Manager
 353   messages which are sent via an RMR connection.
 354
 355 RMR_VCTL_FILE
 356
 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.
 368
 369 RMR_WARNINGS
 370
 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.
 374
 375
 376 SEE ALSO
 377 --------------------------------------------------------------------------------------------
 378
 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)