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 asynch 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 (asynch)
 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 RMR_BIND_IF
 197
 198   This provides the interface that RMr will bind listen
 199   ports to allowing for a single interface to be used rather
 200   than listening across all interfaces. This should be the
 201   IP address assigned to the interface that RMr should
 202   listen on, and if not defined RMr will listen on all
 203   interfaces.
 204
 205 RMR_RTG_SVC
 206
 207   RMr opens a TCP listen socket using the port defined by
 208   this environment variable and expects that the route table
 209   generator process will connect to this port. If not
 210   supplied the port 4561 is used.
 211
 212 RMR_RTG_ISRAW
 213
 214   Is set to 1 if the route table generator is sending
 215   "plain" messages (not using RMr to send messages, 0 if the
 216   rtg is using RMr to send. The default is 1 as we don't
 217   expect the rtg to use RMr.
 218
 219 RMR_SEED_RT
 220
 221   This is used to supply a static route table which can be
 222   used for debugging, testing, or if no route table
 223   generator process is being used to supply the route table.
 224   If not defined, no static table is used and RMr will not
 225   report *ready* until a table is received. The static route
 226   table may contain both the route table (between newrt
 227   start and end records), and the MEID map (between meid_map
 228   start and end records)
 229
 230 RMR_SRC_ID
 231
 232   This is either the name or IP address which is placed into
 233   outbound messages as the message source. This will used
 234   when an RMR based application uses the rmr_rts_msg()
 235   function to return a response to the sender. If not
 236   supplied RMR will use the hostname which in some container
 237   environments might not be routable.
 238
 239 RMR_VCTL_FILE
 240
 241   This supplies the name of a verbosity control file. The
 242   core RMR functions do not produce messages unless there is
 243   a critical failure. However, the route table collection
 244   thread, not a part of the main message processing
 245   component, can write additional messages to standard
 246   error. If this variable is set, RMR will extract the
 247   verbosity level for these messages (0 is silent) from the
 248   first line of the file. Changes to the file are detected
 249   and thus the level can be changed dynamically, however RMR
 250   will only suss out this variable during initialisation, so
 251   it is impossible to enable verbosity after startup.
 252
 253 RMR_WARNINGS
 254
 255   If set to 1, RMR will write some warnings which are
 256   non-performance impacting. If the variable is not defined,
 257   or set to 0, RMR will not write these additional warnings.
 258
 259
 260 SEE ALSO
 261 --------------------------------------------------------------------------------------------
 262
 263 rmr_alloc_msg(3), rmr_tralloc_msg(3), rmr_call(3),
 264 rmr_free_msg(3), rmr_init(3), rmr_init_trace(3),
 265 rmr_get_meid(3), rmr_get_src(3), rmr_get_srcip(3),
 266 rmr_get_trace(3), rmr_get_trlen(3), rmr_get_xact(3),
 267 rmr_payload_size(3), rmr_rcv_msg(3), rmr_rcv_specific(3),
 268 rmr_rts_msg(3), rmr_ready(3), rmr_fib(3), rmr_has_str(3),
 269 rmr_tokenise(3), rmr_mk_ring(3), rmr_realloc_payload(3),
 270 rmr_ring_free(3), rmr_set_trace(3), rmr_torcv_msg(3),
 271 rmr_wh_open(3), rmr_wh_send_msg(3)