caps2caps

caps2caps synchronizes CAPS servers in real-time

Description

caps2caps can connect two CAPS server instances to synchronize waveforms and other data in real time. When one server 1 fails and the other one, server 2, continues to operate, the server 1 can back fill the data as soon as it becomes alive again. caps2caps can also transfer the meta data of the input CAPS server, connected plugins and hardware information to the receiving server allowing them to be jointly displayed and analysed in CAPS server’s web interface for all transferring caps2caps instances.

caps2caps instances connecting two CAPS servers transferring data from the remote into the local server. Here, caps2caps runs on the receiving server which can be exchanged with the input server.

Operation

caps2caps can run on either server to pull the data from the input server pushing them to the output server:

• Run on the receiving output server transferring data from a remote input CAPS server to the receiving CAPS server running locally.

  Advantages:

  • Receiving server controls the data request.

  • Configuration is easy to adjust, module is easy to maintain.

  • caps2caps consumes only little hardware resources on the input but mostly on the output server which may be easier to access and control.

  Disadvantages:

  • For each input source a separate instance of caps2caps must be set up and configured.

  • Each input source must be accessible from the receiving server which potentially requires the configuration of static IP addresses, VPN, firewall and access parameters of the input CAPS server.

  • Plugin and hardware meta data of the input server are not transferred and cannot be jointly visualised on the output server’s CAPS web interface.

• Run on the input server transferring data from the locally running input CAPS server to the receiving CAPS server running remotely.

  Advantages:

  • No static host address is required for the input server.

  • Access and firewall rules need to be configured only on the receiving server.

  • Plugin meta data such as channel or traffic information as well as hardware and SOH details such as CPU usage of the input server are transferred. They can be jointly visualised on the output server’s CAPS web interface for all input servers.

  Disadvantages:

  • On each input server one instance of caps2caps must be configured, maintained and operated which may require external access to this server.

  • caps2caps consumes resources on the input server which may be limited.

The time window of the requested data and their transfer to the output server depends on the configuration of time-window parameters such as begin, end, maxDays, days and daysBefore. These parameters are considered initially per stream unless a journal exist for that stream. Further limitations to particular streams is configurable by streams and outOfOrder.

Journaling

In a journal file caps2caps keeps track of packages received and acknowledged by the receiving CAPS server. The journal file contains the per-stream information on the end time of the latest data package received by the output server. The journal is considered when establishing new connections to the input CAPS server in order to not request data again after case of a restart or in case of a loss of connection to a server. For each stream the begin time of the request time window is the journal time. Only if a journal is unavailable, the configured begin time (begin or days) is considered for defining request time-windows.

Warning

The actual journal file is defined by journal.file. When operating multiple instances of caps2caps on the same SeisComP system, assure to configure the files uniquely avoiding confusion between the instances.

Situations

Data transfer may be affected by different situations of which

• Regular operation

• On-demand data injection

• Backfilling (last-in/first out)

are outlined below. The situations may establish in isolation or simultaneously.

Regular operation

During regular operation CAPS plugins make the data automatically and in real time available on the input server. caps2caps synchronizes the data automatically and in real time with the output CAPS server running on either side. The data is transferred in timely order in a first-in/first-out (fifo) fashion. The request time window results from configuration or per-stream journals.

Regualar operation. Here, caps2caps runs on the input server which can be exchanged with the receiving server.

On-demand data injection

Data may be injected into a CAPS server on demand by a CAPS plugin such as caps2caps or rs2caps. This may create new past data in a CAPS archive. When synchronizing this CAPS archive with another output CAPS server during regular operation, it is not guaranteed that the data is also transferred to the output CAPS server. That has to do with the caps2caps plugin handling streams (section Journaling).

Setting the request time window from the journal can lead to unintended behavior when past data is injected on demand into the input CAPS server and the start time of the data is before the current begin of the requested time window. In this case no data is transferred between the CAPS server instances.

For injecting data on demand and synchronization to two CAPS servers we therefore recommend to send the data to both CAPS servers separately ensuring that both servers store the data. For rs2caps this works similar to:

rs2caps -I file.mseed --passthrough -O server1:18003
rs2caps -I file.mseed --passthrough -O server2:18003

In the future, we might have a better solution for this use case.

Backfilling

Backfilling describes the transfer of data that were received on the input server with significant delay or after longer disconnection between the input and output servers but not as in regular operation.

Injection of data with significant delay or after longer disconnection between the input and output servers

In such a situation, backfilling prioritizes the latest data over transferring the data in timely order. Backfilling therefore transfers data similar to a last-in/first-out manner which is essential to rapid-response and early warning systems.

Data transfer is re-established prioritizing most recent data until backfilling is complete when regular operation continues.

The backfilling strategy is configurable and affects real time requests, that are requests with an open end time, only. If communications are restored after a significant outage, it may take some time to transfer all missing packages due to the limited bandwidth available. By default data is transmitted in order of record start time. However, there are use cases where it is desirable to prioritize the latest packages to get access to real time data as soon as possible.

For this reason, the plugin supports two backfilling modes configurable by backfilling.mode:

• Pull: During handshake all requests with no end time (open) are checked. For each request where the difference between system time and start time is greater than the value of backfilling.maxRealTimeGap the request will be split into two.

• Push: Start times of outgoing packets for requests are checked. For each request where the difference between system time and start time is greater than the value of backfilling.maxRealTimeGap the request will be split into two.

The backfilling mode can be set as follows:

backfilling.mode = PUSH

The time window calculation in Push and Pull mode is the same and the split time is calculated as follows:

splitTime = systemTime - marginRealTimeGap

Then there are two requests:

• A new backfilling request with the time window [startTime~splitTime]

• A real time request with the time window [spitTime~]

The marginRealTimeGap value can be set in the configuration with

backfilling.marginRealTimeGap = 30

To enable the backfilling feature the option backfilling.maxRealTimeGap must be set like

backfilling.maxRealTimeGap = 60

which sets the maximum real-time data gap in seconds.

Note

The configured output buffer size has an effect on the data prioritization as all buffered packages are forwarded to the network stack before they are buffered. That means the TCP implementation manages the packages. Let’s assume the following scenario:

• 1 MB buffer size,

• A few records/samples of real time data and more than 1 MB historical data,

• Network bandwidth 8 kB/s.

In this scenario the outgoing buffer fills up immediately with historical data and it take some time to transfer the data due to the low bandwidth. This initial delay remains until all historical data has been transferred. Keep the buffer size low to avoid larger delays. The downside of this approach is that the general throughput is lower as fewer packages are in-flight and the plugin has to wait for server acknowledges.

Examples

• Run caps2caps as daemon module.

  1. Configure input and output hosts (input.address, output.address) in caps2caps module configuration, caps2caps.cfg.

  2. Enable and start caps2caps

     seiscomp enable caps2caps
     seiscomp start caps2caps
     

• Run caps2caps on demand in a terminal with specific, explicitly specifying input and output hosts without encryption

  caps2caps -I caps://inputServer:18002 -O caps://outputServer:18003
  

  The same as above but with encrypted data transfer controlled by user name and password

  caps2caps -I capss://user:password@inputServer:18002 -O capss://user:password@inputServer:output:18003
  

• Pull or push data depending on module configuration but ignore the journal file. This allows resending the data but it may cause a very big amount of data to be transferred. Ignoring the journal file must therefore be considered with care!

  caps2caps -j ""
  

Module Configuration

etc/defaults/global.cfg

etc/defaults/caps2caps.cfg

etc/global.cfg

etc/caps2caps.cfg

~/.seiscomp/global.cfg

~/.seiscomp/caps2caps.cfg

caps2caps inherits global options.

Note

Modules/plugins may require a license file. The default path to license files is @DATADIR@/licenses/ which can be overridden by global configuration of the parameter gempa.licensePath. Example:

gempa.licensePath = @CONFIGDIR@/licenses

streams

Type: string

Comma separated list of streams. Stream format: NET.STA.LOC.CHA. Streams may contain wildcards

begin

Type: string

Begin of data time window. All SeisComP time formats are supported. Example: YYYY-MM-DDThh:mm:ss.sss .

If omitted, the current UTC time is used. This value sets the initial start time for all requests. When data is received before and a journal is available, the begin time for each stream is taken from the journal each time the module is started and the configured value is ignored for the respective data stream.

end

Type: string

End of data time window. All SeisComP time formats are supported. Example: YYYY-MM-DDThh:mm:ss.sss .

maxDays

Default: -1

Unit: day

Type: int

Maximum number of days to acquire regardless if a time window is configured or read from journal. Values <= 0 disable the check. The reference time is either the stream’s end time or, if no end time is specified, the current time in UTC.

days

Default: -1

Unit: day

Type: int

The begin of the data time window as number of days before current time.

daysBefore

Default: -1

Unit: day

Type: int

The end of the data time window as number of days before current time.

timeWindowUpdateInterval

Default: -1

Unit: s

Type: int

The time interval at which the relative request time window defined by option days and/or daysBefore is updated. Values <= 0 disable the update. This feature is supported in archive mode only. A typical use case is when data has to be transmitted continuously with a time delay.

realtime

Default: true

Type: boolean

Only fetch real-time but no archived data.

outOfOrder

Default: false

Type: boolean

Allow transfering out-of-order data which is not reveived in timely order.

Note

input.* Configuration of data input host.

input.address

Type: string

URL. Format: [[caps|capss]://][user:pass@]host[:port] .

output.address

Default: localhost:18003

Type: string

Data output URL [[caps|capss]://][user:pass@]host[:port]. This parameter superseds the host and port parameter of previous versions and takes precedence.

output.host

Default: localhost

Type: string

Deprecated: Data output host. Use "output.address" instead.

output.port

Default: 18003

Type: int

Deprecated: Data output port. Use "output.address" instead.

output.timeout

Default: 60

Unit: s

Type: int

Timeout when sending a packet. If the timeout expires, the connection will be closed and re-established.

output.maxFutureEndTime

Default: 120

Unit: s

Type: int

Maximum allowed relative end time for packets. If the packet end time is greater than the current time plus this value, the packet will be discarded.

output.bufferSize

Default: 1048576

Unit: bytes

Type: uint

Size (bytes) of the packet buffer.

output.backfillingBufferSize

Default: 0

Unit: s

Type: int

Length of backfilling buffer. Whenever a gap is detected, records will be held in a buffer and not sent out. Records are flushed from front to back if the buffer size is exceeded.

output.maxFutureEndTime

Default: 3600

Unit: s

Type: int

CAPS maximum allowed packet end time. If a packet’s end time is larger than current time plus this value the packet is discarded.

output.mseed.enable

Default: false

Type: boolean

Enable on-the-fly miniSEED encoding. If the encoder does not support the input type of a packet, it will be forwarded. Re-encoding of miniSEED packets is not supported.

output.mseed.encoding

Default: Steim2

Type: string

miniSEED encoding to use. (Uncompressed, Steim1 or Steim2)

output.mseed.recordLength

Default: 9

Type: uint

miniSEED record length. The value represents the exponent in the expression 2^n, e.g., 2^9 = 512 bytes

journal.file

Default: @ROOTDIR@/var/run/caps2caps/journal

Type: file

Journal file to store stream states.

journal.flush

Default: 10

Unit: s

Type: uint

Flush stream states to journal file every given seconds.

journal.waitForAck

Default: 60

Unit: s

Type: uint

Wait when a sync has been forced, up to the given seconds.

journal.waitForLastAck

Default: 5

Unit: s

Type: uint

Wait on shutdown to receive acknownledgement messages, up to the given seconds.

statusLog.enable

Default: false

Type: boolean

Log information status information e.g. max bytes buffered.

statusLog.flush

Default: 10

Type: uint

Flush status every given seconds to disk.

host.storage

Default: @LOGDIR@

Type: directory

Path to storage used to determine available disc space and capacity.

host.os

Type: string

Set the operating system information, such as Ubuntu 24.04.1 LTS. If this information is not provided, the plugin will attempt to read the value from the PRETTY_NAME variable in the /etc/os-release file.

host.agent

Type: string

Set the agent string to send to the CAPS server. By default, the application name is used.

host.group

Type: string

Set the group string to send to the CAPS server.

Note

backfilling.* Controls backfilling parameters for open streams (with no end time).

backfilling.mode

Default: PUSH

Type: string

Values: PULL,PUSH

Set the backfilling mode:

PULL: During handshake all requests with no end time(open) are checked. For each request where the difference between system time and start time is greater than the value of backfilling.maxRealTimeGap the request will be split into two requests. PUSH: Start times of outgoing packets for requests are checked. For each request where the difference between system time and start time is greater than the value of backfilling.maxRealTimeGap the request will be split into two.

backfilling.maxRealTimeGap

Default: -1

Unit: s

Type: int

Sets the maximum real-time data gap in seconds. This means, if the start time of the requested time window of a channel is before this value with respect to the current system time then the request is split into a real-time request starting at system time - marginRealTimeGap and a backfill request from requested start time to time - marginRealTimeGap. That prioritizes real time data and backfills old data in parallel.

backfilling.marginRealTimeGap

Default: 60

Unit: s

Type: int

The time margin used to request real time data in combination with maxRealTimeGap with respect to system time.

Command-Line Options

Generic

-h, --help

Show help message.

-V, --version

Show version information.

--config-file file

The alternative module configuration file. When this option is used, the module configuration is only read from the given file and no other configuration stage is considered. Therefore, all configuration including the definition of plugins must be contained in that file or given along with other command-line options such as --plugins.

--plugins arg

Load given plugins.

-D, --daemon

Run as daemon. This means the application will fork itself and doesn’t need to be started with &.

Verbosity

--verbosity arg

Verbosity level [0..4]. 0:quiet, 1:error, 2:warning, 3:info, 4:debug.

-v, --v

Increase verbosity level (may be repeated, e.g., -vv).

-q, --quiet

Quiet mode: no logging output.

--print-component arg

For each log entry print the component right after the log level. By default the component output is enabled for file output but disabled for console output.

--component arg

Limit the logging to a certain component. This option can be given more than once.

-s, --syslog

Use syslog logging backend. The output usually goes to /var/lib/messages.

-l, --lockfile arg

Path to lock file.

--console arg

Send log output to stdout.

--debug

Execute in debug mode. Equivalent to --verbosity=4 --console=1 .

--trace

Execute in trace mode. Equivalent to --verbosity=4 --console=1 --print-component=1 --print-context=1 .

--log-file arg

Use alternative log file.

Input

-I, --input arg

Overrides configuration parameter input.address.

URL of data input host. Format: [[caps|capss]://][user:password@]host[:port] .

--max-real-time-gap

Maximum length of data gap after reconnecting. If exceeded, a real-time stream and backfilling stream will be created in parallel. Setting this value will give highest priority to real-time streams, e.g., for rapid response systems.

Streams

-i, --inventory arg

Inventory XML defining the streams to add.

-A, --add-stream arg

List of streamIDs [NET.STA.LOC.CHA] to add. Wildcards are supported. Use comma-separation without blanks for multiple IDs.

--begin arg

Start time of data request. Applied only on streams not found in the journal. Format: ‘YYYY-MM-DD hh:mm:ss.sss’.

--end arg

End time of data request. Format: ‘YYYY-MM-DD hh:mm:ss.sss’.

--max-days arg

Unit: day

Maximum number of days to acquire regardless if the time window is configured or read from journal. A value of 0 or less disables the check.

--days arg

Unit: day

Begin of data request time window given as days before current time. Applied only on streams not found in the journal.

--days-before arg

Unit: day

End of data request time window given as number of days before current time.

Mode

--archive

Disable real-time mode. Only archived data is fetched and missing records are ignored.

--out-of-order

Use to enable out-of-order mode. Allows transfering data which is not in timely order.

Output

-O, --output arg

Overrides configuration parameter output.address.

This is the CAPS server which shall receive the data.

-b, --buffer-size arg

Unit: bytes

Size (bytes) of the journal buffer. If the value ist exceeded, a synchronization of the journal is forced.

--backfilling arg

Default: 0

Unit: s

Buffer size in seconds for backfilling gaps.

--mseed

Enable on-the-fly miniSEED encoding. If the encoder does not support the input type of a packet, it will be forwarded. Re-encoding of miniSEED packets is not supported.

--encoding arg

miniSEED encoding to use: Uncompressed, Steim1 or Steim2.

--rec-len arg

miniSEED record length expressed as a power of 2. A 512 byte record would be 9.

--max-future-endtime arg

Unit: s

Maximum allowed relative end time for packets. If the packet end time is greater than the current time plus this value, the packet will be discarded. By default this value is set to 120 seconds.

--dump-packets

Dump packets to stdout.

--test

Disable socket communication.

--dump

Dump all received data to stdout and don’t use the input port.

Journal

-j, --journal arg

File to store stream states. Use an empty string to log to stdout.

-f, --flush arg

Unit: s

Flush stream states to disk every n seconds.

--wait-for-ack arg

Unit: s

Wait when a sync has been forced, up to n seconds.

-w, --wait-for-last-ack arg

Unit: s

Wait on shutdown to receive acknownledgement messages, up to the given number of seconds.

Status

--status-log

Log information status information, e.g., max bytes buffered.

--status-flush arg

Unit: s

Flush status every n seconds to disk.

Host

--host-storage

Path to storage used to determine available disc space and capacity.

--host-os

Set the operating system information, such as Ubuntu 24.04.1 LTS to send to the CAPS server.

--host-agent

Set the agent string to send to the CAPS server.

--host-group

Set the group string to send to the CAPS server.