.if false
==================================================================================
	Copyright (c) 2019 Nokia
	Copyright (c) 2018-2019 AT&T Intellectual Property.

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.
==================================================================================
.fi

.if false
	Mnemonic:	config.im
	Abstract:	Major section discussing for configuration.
	Date:		2 August 2019
	Author:		E. Scott Daniels
.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.

.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).


&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.


&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:

&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

	&di(RMR_RTG_SVC)	The port RMR will listen on for route manager connections. If not defined 4561 is used.
	&half_space

	&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

	&di(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. 
						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
						sent as the message source. Only the host name will be sent as the source in the message header.
&end_dlist
&uindent
.st &textsize
&space

&h2(Logging)
RMR does &bold(not) use any logging libraries; any error or warning messages are written to standard error. 
.if false 
 &note .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.
.cn end
.fi
RMR messages are written with one of three prefix strings:


&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.
				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. 
				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
				that the cause of the problem be investigated.
&end_dlist
&space
&uindent