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. 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.
  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 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.
 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 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
 204   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 well known address and port.
 218
 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**
 223   defined.
 224
 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).
 229
 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.
 233
 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.
 239
 240
 241 RMR_RTG_SVC
 242
 243   The value of this variable depends on the Route Manager in
 244   use.
 245
 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.
 249
 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.
 253
 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.
 258
 259
 260 RMR_HR_LOG
 261
 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
 267   of 1 is assumed.
 268
 269
 270 RMR_LOG_VLEVEL
 271
 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:
 278
 279
 280 0
 281
 282   Off; no messages of any sort are written.
 283
 284
 285 1
 286
 287   Only critical messages are written (default if this
 288   variable does not exist)
 289
 290
 291 2
 292
 293   Errors and all messages written with a lower value.
 294
 295
 296 3
 297
 298   Warnings and all messages written with a lower value.
 299
 300
 301 4
 302
 303   Informational and all messages written with a lower
 304   value.
 305
 306
 307 5
 308
 309   Debugging mode -- all messages written, however this
 310   requires RMR to have been compiled with debugging
 311   support enabled.
 312
 313
 314
 315 RMR_RTG_ISRAW
 316
 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.
 321
 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
 329   variable.
 330
 331 RMR_SEED_RT
 332
 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)
 341
 342 RMR_SRC_ID
 343
 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.
 350
 351   The value of this variable is also used for Route Manager
 352   messages which are sent via an RMR connection.
 353
 354 RMR_VCTL_FILE
 355
 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.
 367
 368 RMR_WARNINGS
 369
 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.
 373
 374
 375 SEE ALSO
 376 --------------------------------------------------------------------------------------------
 377
 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)