.fi
&h1(Configuration and Control)
-With the assumption that most RMR based applications will be executed in a containerised
-environment, there are some underlying mechanics which the developer may need to know
-in order to properly provide a configuration specification to the container management
-system.
-The following paragraphs briefly discuss these.
+With the assumption that most RMR based applications will be executed
+in a containerised environment, there are some underlying mechanics
+which the developer may need to know in order to properly provide a
+configuration specification to the container management system. The
+following paragraphs briefly discuss these.
.sp .1
&h2(TCP Ports)
-RMR requires two (2) TCP listen ports: one for general application to application communications
-and one for route table updates.
-The general communication port is specified by the application at the time RMR is initialised.
-The port used to listen for route table updates is likely to be a constant port shared by all
-applications provided they are running in separate containers.
-To that end, the port number defaults to 4561, but can be configured with an environment variable
-(see later paragraph in this section).
+RMR requires two (2) TCP listen ports: one for general
+application-to-application communications and one for route-table
+updates. The general communication port is specified by the
+application at the time RMR is initialised. The port used to listen
+for route table updates is likely to be a constant port shared by all
+applications provided they are running in separate containers. To
+that end, the port number defaults to 4561, but can be configured with
+an environment variable (see later paragraph in this section).
&h2(Host Names)
-RMR is typically host name agnostic.
-Route table entries may contain endpoints defined either by host name or IP address.
-In the container world the concept of a &ital(service name) might exist, and likely is different
-than a host name.
-RMR's only requirement with respect to host names is that a name used on a route table entry must
-be resolvable via the &cw(gethostbyname) system call.
+RMR is typically host name agnostic. Route table entries may contain
+endpoints defined either by host name or IP address. In the container
+world the concept of a &ital(service name) might exist, and likely is
+different than a host name. RMR's only requirement with respect to
+host names is that a name used on a route table entry must be
+resolvable via the &cw(gethostbyname) system call.
&h2(Environment Variables)
-Several environment variables are recognised by RMR which,
-in general, are used to define interfaces and listen ports (e.g. the route table update
-listen port), or debugging information.
-Generally this information is system controlled and thus RMR expects this information to
-be defined in the environment rather than provided by the application.
-The following is a list of the environment variables which RMR recognises:
+Several environment variables are recognised by RMR which, in general,
+are used to define interfaces and listen ports (e.g. the route table
+update listen port), or debugging information. Generally this
+information is system controlled and thus RMR expects this information
+to be defined in the environment rather than provided by the
+application. The following is a list of the environment variables
+which RMR recognises:
&half_space
-.st 8p
&indent
&beg_dlist( 1.25i &ditext )
- &di(RMR_BIND_IF) The interface to bind to listen ports to. If not defined 0.0.0.0 (all interfaces) is assumed.
- &half_space
+ &ditem(RMR_BIND_IF) The interface to bind to listen ports to. If not defined 0.0.0.0 (all interfaces) is assumed.
- &di(RMR_RTG_SVC) The port RMR will listen on for route manager connections. If not defined 4561 is used.
- &half_space
+ &ditem(RMR_RTG_SVC) This variabe supplies the host:port (or address:port) of the Route Manager (route table generator)
+ process. RMR will attempt to connect to this address port combination and request a route table.
+ If it is desired to prevent RMR from attempting to request a dynamic route table, the value of this
+ variable should be set to "-1." If not set &cw(routemgr:4561) is assumed.
- &di(RMR_SEED_RT) Where RMR expects to find the name of the seed (static) route table. If not defined no static table is read.
- &half_space
+ &ditem(RMR_CTL_PORT) This is the port which RMR's route table collector thread will use to listen for RMR messages
+ from the route manager (route table generator). By default this is 4561, and must be unique for
+ each RMR process running on the host/container.
- &di(RMR_RTG_ISRAW) If the value set to 0, RMR expects the route table manager messages to be messages with and RMR header.
+ &ditem(RMR_RTREQ_FREQ) When a new route table is needed, the frequency that RMR sends a route table request to the
+ Route Manager defaults to 5 seconds. This variable can be used to set the frequency to a value between
+ 1 and 300 seconds inclusive.
+
+ &ditem(RMR_SEED_RT) Where RMR expects to find the name of the seed (static) route table. If not defined no static table is read.
+
+ &ditem(RMR_RTG_ISRAW) If the value set to 0, RMR expects the route table manager messages to be messages with and RMR header.
If this is not defined messages are assumed to be "raw" (without an RMR header.
- &half_space
- &di(RMR_VCTL_FILE) Provides a file which is used to set the verbose level of the route table collection thread.
- The first line of the file is read and expected to contain an integer value to set the verbose level.
+ &ditem(RMR_VCTL_FILE) Provides a file which is used to set the verbose level of the route table collection thread.
+ The first line of the file is read and expected to contain an integer value to set the verbose level.
The value may be changed at any time and the route table thread will adjust accordingly.
- &half_space
- &di(RMR_SRC_NAMEONLY) If the value of this variable is greater than 0, RMR will not permit the IP address to be
+ &ditem(RMR_SRC_NAMEONLY) If the value of this variable is greater than 0, RMR will not permit the IP address to be
sent as the message source. Only the host name will be sent as the source in the message header.
&end_dlist
&uindent
&space
&h2(Logging)
-RMR does &bold(not) use any logging libraries; any error or warning messages are written to standard error.
-.if false
+RMR does &bold(not) use any logging libraries; any error or warning messages are written to standard error.
+.if false
¬e .sm .
.cn l=&cn_line_len i=0 start &atbot Times-roman 8p .7i
This is standard practice for container based applications as it makes error output easily available to operations.
&half_space
&indent
&beg_dlist( .6i &ditext )
- &di(^[CRI]) The event is of a critical nature and it is unlikely that RMR will continue to operate correctly if at all.
+ &ditem(^[CRI]) The event is of a critical nature and it is unlikely that RMR will continue to operate correctly if at all.
It is almost certain that immediate action will be needed to resolve the issue.
- &half_space
- &di(^[ERR]) The event is not expected and RMR is not able to handle it. There is a small chance that continued operation
- will be negatively impacted.
+ &ditem(^[ERR]) The event is not expected and RMR is not able to handle it. There is a small chance that continued operation
+ will be negatively impacted.
Eventual action to diagnose and correct the issue will be necessary.
- &half_space
- &di(^[WRN]) The event was not expected by RMR, but can be worked round. Normal operation will continue, but it is recommended
+ &ditem(^[WRN]) The event was not expected by RMR, but can be worked round. Normal operation will continue, but it is recommended
that the cause of the problem be investigated.
&end_dlist
&space
Code Review / ric-plt / lib / rmr.git / blobdiff