NAME¶
ramsgate - Remote AMS gateway daemon
SYNOPSIS¶
ramsgate application_name authority_name
[
bundles_TTL]
DESCRIPTION¶
ramsgate is a background "daemon" task that functions as a
Remote AMS gateway.
application_name and
authority_name must
identify an AMS venture that is known to operate in the local continuum, as
noted in the MIB for the
ramsgate application module.
ramsgate will register as an application module in the root unit of the
indicated venture, so a configuration server for the local continuum and a
registrar for the root unit of the indicated venture (which may both be
instantiated in a single
amsd daemon task) must be running in order for
ramsgate to commence operations.
ramsgate with communicate with other RAMS gateway modules in other
continua by means of the RAMS network protocol noted in the RAMS gateway
endpoint ID for the local continuum, as identified (explicitly or implicitly)
in the MIB.
If the RAMS network protocol is "bp" (i.e., the DTN Bundle Protocol),
then an ION Bundle Protocol node must be operating on the local computer and
that node must be registered in the BP endpoint identified by the RAMS gateway
endpoint ID for the local continuum. Moreover, in this case the value of
bundles_TTL - if specified - will be taken as the lifetime in seconds
that is to be declared for all "bundles" issued by
ramsgate;
bundles_TTL defaults to 86400 seconds (one day) if omitted.
EXIT STATUS¶
- "0"
- ramsgate terminated normally.
- "1"
- ramsgate failed, for reasons noted in the ion.log file; the task
terminated.
FILES¶
A MIB initialization file with the applicable default name (see
amsrc(5))
must be present.
ramsgate records all "petitions" (requests for data on behalf
of AMS modules in other continua) in a file named "petition.log". At
startup, the
ramsgate daemon automatically reads and processes all
petitions in the petition.log file just as if they were received in real time.
Note that this means that you can cause petitions to be, in effect,
"pre-received" by simply editing this file prior to startup. This
can be an especially effective way to configure a RAMS network in which long
signal propagation times would otherwise retard real-time petitioning and thus
delay the onset of fully functional message exchange.
ENVIRONMENT¶
No environment variables apply.
DIAGNOSTICS¶
The following diagnostics may be issued to the
ion.log log file:
- ramsgate can't run.
- RAMS gateway functionality failed, for reasons noted in the ion.log
file.
BUGS¶
Note that the AMS design principle of receiving messages immediately and
enqueuing them for eventual ingestion by the application module - rather than
imposing application-layer flow control on AMS message traffic - enables high
performance but makes
ramsgate vulnerable to message spikes. Since
production and transmission of bundles is typically slower than AMS message
reception over TCP service, the ION working memory and/or heap space available
for AMS event insertion and/or bundle production can be quickly exhausted if a
high rate of application message production is sustained for a long enough
time. Mechanisms for defending against this sort of failure are under study,
but for now the best mitigations are simply to (a) build with compiler option
-DAMS_INDUSTRIAL=1, (b) allocate as much space as possible to ION working
memory and SDR heap (see
ionconfig(5)) and (c) limit the rate of AMS
message issuance.
Report bugs to <ion-bugs@korgano.eecs.ohiou.edu>
SEE ALSO¶
amsrc(5),
petition_log(5)