Page History

...

Normally, when the RMR initialisation function is invoked, a listener is started to receive route table information from a route manager process.  During testing it is often useful to be able to supply a static table which is available should no route management process exist, or to provide a seed table to use before the first table is delivered.  The environment variable RMR_SEED_RT  can be set to provide the RMR initialisation function with the name of the static table to use. If a static table is provided, it will be loaded only once, and if a route manager subsequently connects and delivers a complete or updated table, it will override the static table. 

Routing Using MEID

Starting with version 1.13.0, RMR provides the ability to select the endpoint for a message based on the MEID (managed equipment ID) in the message, rather than selecting the endpoint from the round-robin list for the matching route table entry.  To make use of this, there must be one or more route table entries which list the special endpoint name %meid instead of providing a round robin list. As an example, consider the following route table entry: 

mse| 1000,forwarder:43086 | 10 | %meid

The final field of the entry doesn't specify a round-robin group which means that when an application attempts to send a message with type 1000, and the subscription ID of 10, the MEID in the message will be used to select the endpoint.

MEID endpoint selection

To select an endpoint for the message based on the MEID in a message, RMR must know which endpoint owns the MEID.  This information, known as an MEID map,  is provided by the Routing Manager over the same communication path as the route table is supplied.  The following is the syntax for an MEID map.

  meid_map | start
  mme_ar | <owner-endpoint> | <meid> [<meid>...]
  mme_del | <meid> [<meid>...]
  meid_map | end | <count>

The mme_ar records are add/update records and allow for the list of MEIDs to be associated with (owned by) the indicated endpoint. The <owner-endpoint> is the hostname:port, or IP address and port, of the application which owns the MEID and thus should receive any messages which are routed based on a route table entry with %meid as the round-robin group.   The mme_del records allow  for MEIDs to be deleted from RMR's view. Finally, the <count> is the number of add/replace and delete records which were sent; if RMR does not match the <count> value to the number of records, then it will not add the data to the table.   Updates only need to list the ownership changes that are necessary; in other words, the Route Manager does not need to supply all of the MEID relationships with each update.

If a static seed file is being used for the route table, a second section can be given which supplies the MEID map. The following is a small example of a seed file:

newrt|start
        mse|0|-1| %meid
        mse|1|-1|172.19.0.2:4560
        mse|2|-1|172.19.0.2:4560
        mse|3|-1|172.19.0.2:4560
        mse|4|-1|172.19.0.2:4560
        mse|5|-1|172.19.0.2:4560
newrt|end

meid_map | start
        mme_ar| 172.19.0.2:4560 | meid000 meid001 meid002 meid003 meid004 meid005
        mme_ar| 172.19.0.42:4560 | meid100 meid101 meid102 meid103
        mme_del | meid1000
meid_map | end | 1

The tables above will route all messages with a message type of 0 based on the MEID.  There are 10 meids which are owned by two different endpoints.  The table also deletes the MEID meid1000 from RMR's view.

Reserved Message Types

RMR is currently reserving message types in the range of 0 through 99 (inclusive) for its own use.  Please do not use these types in any production or test environment as the results may be undesired.

...