doc/src/man/rmr.7.xfm

   1 .if false
   2 ==================================================================================
   3    Copyright (c) 2019 Nokia
   4    Copyright (c) 2018-2019 AT&T Intellectual Property.
   5
   6    Licensed under the Apache License, Version 2.0 (the "License");
   7    you may not use this file except in compliance with the License.
   8    You may obtain a copy of the License at
   9
  10        http://www.apache.org/licenses/LICENSE-2.0
  11
  12    Unless required by applicable law or agreed to in writing, software
  13    distributed under the License is distributed on an "AS IS" BASIS,
  14    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  15    See the License for the specific language governing permissions and
  16    limitations under the License.
  17 ==================================================================================
  18 .fi
  19 .if false
  20     Mnemonic    rmr.7.xfm
  21     Abstract    The manual page for the whole RMR library
  22     Author      E. Scott Daniels
  23     Date        29 January 2019
  24 .fi
  25
  26 .gv e LIB lib
  27 .im &{lib}/man/setup.im
  28
  29 &line_len(6i)
  30
  31 &h1(RMR Library)
  32
  33 &h2(NAME)
  34     RMR -- Ric Message Router Library
  35
  36 &h2(DESCRIPTION)
  37 RMR is a library which provides  a user application with the ability
  38 to send and receive messages to/from  other RMR based applications
  39 without having to understand the underlying messaging transport environment (e.g., SI95)
  40 and without needing to know which other endpoint applications are currently
  41 available and accepting messages.
  42 To do this, RMR depends on a routing table generated by an external source.
  43 This table is used to determine the destination endpoint of each message sent by mapping the
  44 message type T (supplied by the user application) to an endpoint entry.
  45 Once determined, the message is sent directly to the endpoint.
  46 The user application is unaware of which endpoint actually receives the
  47 message, and in some cases whether that message was sent to multiple
  48 applications.
  49
  50 &space
  51 RMR functions do provide for the ability to respond to the specific source
  52 instance of a message allowing for either a request response, or call
  53 response relationship when needed.
  54
  55
  56 &h3(The Route Table)
  57 The library must be given a route table which maps message types
  58 (integers) to endpoint groups such that each time a message of type T
  59 is sent, the message is delivered to one member of each group
  60 associated with T. For example, message type 2 might route to two
  61 different groups where group A has two members, worker1 and worker2,
  62 while group B has only one member, logger1.
  63
  64 &space
  65 The route table consists of a start record, one or more table entry
  66 records, and an end record.  All table records contain fields
  67 separated with vertical bars (|), and allow for trailing comments with
  68 the standard shell comment symbol (hash, #) provided that the start of
  69 the comment is separated from the last token on the record by one or
  70 more spaces. Leading and trailing white space in each field is
  71 ignored. The route table supports two entry types: &ital(rte) and
  72 &ital(mse).
  73
  74 &space
  75 A &ital(rte) entry defines a message type, an optional sender
  76 application, and the endpoint(s) which accept the indicated message
  77 type.  However, this format is deprecated and may be removed in a
  78 future version. An example record appears next.
  79
  80 &ex_start
  81     rte | 1 | app10:4560
  82 &ex_end
  83
  84 &space
  85 The second type of entry is &ital(mse).  This entry defines a message
  86 type, an optional sender application, a subscription ID, and a
  87 collection of endpoints. An example record appears next.
  88 &ex_start
  89     mse | 1000,forwarder:43086 | 10 | app2:43086
  90 &ex_end
  91
  92 &space
  93 It is the responsibility of the route table generator to know which
  94 endpoints belong to which groups, and which groups accept which
  95 message types.  Once understood, the route table generator publishes a
  96 table that is ingested by RMR and used for mapping messages to end
  97 points.
  98
  99 .sp
 100 The following is a simple route table which causes message types 0
 101 through 9 to be routed to specific applications:
 102
 103 &ex_start
 104 newrt|start
 105    mse|0|-1| %meid
 106    mse|1|-1|app10:4560,app11:4560
 107    mse|2|-1|app12:4560
 108    mse|3|-1|app14:4560
 109    mse|4|-1|app18:4560
 110    mse|5|-1|app01:4560
 111    mse|6|-1|app02:4560
 112    mse|7|-1|app03:4560
 113    mse|8|-1|app04:4560
 114    mse|9|-1|app05:4560
 115 newrt|end
 116 &ex_end
 117
 118 &space
 119 The special endpoint "%meid" indicates that the message type (0 in
 120 this case) is to be routed to the endpoint which has been listed as
 121 the "owner" for the meid appearing in the message.  MEID ownership is
 122 communicated to RMR using the same Route Table Manager interface and
 123 by supplying a "table" such as the one below:
 124
 125 &ex_start
 126 meid_map | start
 127    mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
 128    mme_ar | control2 | meid100 meid101 meid102 meid103
 129 meid_map | end | 2
 130 &ex_end
 131
 132 &space
 133 This table indicates that the application (endpoint) &ital(control1)
 134 "owns" 6 MEIDs and &ital(control2) owns 4.  When message type 0 is
 135 sent, the MEID in the message will be used to select the endpoint via
 136 this table.
 137
 138 &space
 139 The MEID table will update the existing owner relationships, and add
 140 new ones; it is necessary to send only the changes with the
 141 add/replace (mme_ar) entries in the table.  When necessary, MEIDs can
 142 be deleted by adding an &cw(mme_del) record to the table.  The
 143 following example illustrates how this might look:
 144
 145 &ex_start
 146 meid_map | start
 147    mme_ar | control1 | meid000 meid001 meid002 meid003 meid004 meid005
 148    mme_ar | control2 | meid100 meid101 meid102 meid103
 149    mme_del| meid200 meid401
 150 meid_map | end | 3
 151 &ex_end
 152
 153 &h3(Route Table Syntax)
 154 The following illustrates the syntax for both types of route table entries.
 155
 156 &space
 157 &ex_start
 158 newrt | start
 159 rte | <message-type>[,<sender-endpoint>] | <round-robin-grp>[;<round-robin-grp>]...
 160 mse | <message-type>[,<sender-endpoint>] | <sub-id> | <round-robin-grp>[;<round-robin-grp>]...
 161 newrt | end
 162 &ex_end
 163
 164 &space
 165 A round robin group is one or more endpoints from which one will be
 166 selected to receive the message.  When multiple endpoints are given in
 167 a group, they must be separated with a comma.  An endpoint is an IP
 168 address and port (e.g. 192.158.4.30:8219), or DNS name and port, of
 169 the application that should receive the message type.  If multiple
 170 round-robin groups are given, they must be separated by a semicolon.
 171
 172 &h3(MEID Map Syntax)
 173 The MEID map is similar to the route table.  Entries are used to add
 174 or replace the ownership of one or more MEIDs (mme_ar) or to delete
 175 one or more MEIDs (mme_del).  The following is the syntax for the MEID
 176 map.
 177
 178 &space
 179 &ex_start
 180 meid_map | start
 181 mme_ar | <owner-endpoint> | <meid> [<meid>...]
 182 mme_del | <meid> [<meid>...]
 183 meid_map | end | <count> | <md5sum>
 184 &ex_end
 185
 186 &space
 187 The <count> on the end record indicates the number of mme_ar and mme_del records
 188 which were sent; if the count does not match the whole map is refused and dropped.
 189 The <owner-endpoint> is the endpoint which should receive the message when a message
 190 is routed based on the MEID it contains.
 191 A MEID may be "owned" by only one endpoint, and if supplied multiple times, the last
 192 observed relationship is used.
 193 Each of the lists of MEIDs are blank separated.
 194
 195 &space
 196 The optional <md5sum> on the &ital(end) record should be the computed MD5 hash for all
 197 records which appear between the start and and records.
 198 This allows for a tighter verification that all data was received exactly as the
 199 route manager transmitted them.
 200
 201
 202 &h3(Environment)
 203 To enable configuration of the library behaviour outside of direct user application
 204 control, RMR supports a number of environment variables which provide information
 205 to the library.
 206 The following is a list of the various environment variables, what they control
 207 and the defaults which RMR uses if undefined.
 208
 209 .** the list of environment vars supported
 210 .im &{lib}/man/env_var_list.im
 211
 212
 213 &h2(SEE ALSO )
 214 .ju off
 215 rmr_alloc_msg(3),
 216 rmr_tralloc_msg(3),
 217 rmr_call(3),
 218 rmr_free_msg(3),
 219 rmr_init(3),
 220 rmr_init_trace(3),
 221 rmr_get_meid(3),
 222 rmr_get_src(3),
 223 rmr_get_srcip(3),
 224 rmr_get_trace(3),
 225 rmr_get_trlen(3),
 226 rmr_get_xact(3),
 227 rmr_payload_size(3),
 228 rmr_rcv_msg(3),
 229 rmr_rcv_specific(3),
 230 rmr_rts_msg(3),
 231 rmr_ready(3),
 232 rmr_fib(3),
 233 rmr_has_str(3),
 234 rmr_tokenise(3),
 235 rmr_mk_ring(3),
 236 rmr_realloc_payload(3),
 237 rmr_ring_free(3),
 238 rmr_set_trace(3),
 239 rmr_torcv_msg(3),
 240 rmr_wh_open(3),
 241 rmr_wh_send_msg(3)
 242 .ju on
 243
 244