.. _sec-intro: Introduction ============ The Common Acquisition Protocol Server (|appname|) was developed to fulfill the needs to transfer multi-sensor data from the station to the data center. As nowadays more and more stations with co-located sensors like broadband seismometer, accelerometer, CGPS, temperature, video cameras, etc. are build up, a acquisition protocol is required, which can efficiently handle low- and high-sampled data through one unified protocol. |appname| is a core component of |scname| systems where data redundancy, security and high availability is key. The |appname| package ships with * The :ref:`CAPS server ` serving :term:`miniSEED ` and other multi-format data in real-time and from archive. * :ref:`Data acquisition plugins ` feeding data into the CAPS server. * :ref:`Data retrieval and analysis tools ` including on-demand access to data on the server. Features -------- The core features of |appname| are: * Multi-sensor data transfer including miniSEED records, video streams and :ref:`almost any other format `. * Compehensive data acquisition by all existing plugins for :cite:t:`seedlink` plus additional :ref:`CAPS plugins `. * No inventory required for immediate data acquisition. * Stations can be added without reconfiguring the |appname| server avoiding server downtimes. * Pushing of data from new stations into CAPS without restarting the CAPS server. * Lightweight protocol for minimized packet overhead. * Reliable data transfer, no data loss due to re-transmission of data in case of network outage or server restart. * Archived and real-time data served through one single protocol and one connection. * High-quality data archives: * backfilling of data and correct sorting by time even if records arrive in out of order sequences. * duplicate records in CAPS archives are impossible. Such duplicates may exist in :term:`SDS` archives created by :cite:t:`scart` or :cite:t:`slarchive`. * Rapid response systems are supported by prioritizing recent data when recovering from longer gaps of data acquisition allowing to process the most recent data first before backfilling older data. * :ref:`Data security ` on multiple levels: * secure communication via :ref:`SSL `. * :ref:`User authentication `. * different user and group roles distinguishing read, write or administrative access. * :ref:`fine-grained access control ` on service and stream level for defined users, user groups or IP ranges. * :ref:`Data redundancy ` by real-time connection between two or more CAPS servers. * Easy :ref:`access to data `: * via the :ref:`caps RecordStream ` provided by |scname| :cite:p:`seiscomp` * using :ref:`added tools and interfaces ` also offering meta data information. * via :ref:`Seedlink `. * by built-in standard :ref:`FDSN Web Service `. * by built-in :ref:`Winston Wave Server, WWS `, e.g., to :cite:t:`swarm` by USGS. * by an interactive :ref:`Web interface ` also offering statistics and meta data information. * from :ref:`other CAPS servers `. * through :ref:`telnet interface `. * Server-side downsampling upon client request for optimized data transfer. .. _sec-architecture: Architecture ------------ The figure below shows the architecture of :term:`CAPS`. The central component is the server, which receives data from sensors or other data centers, stores it into an archive and provides it to connected clients. The connection between a data provider and :term:`CAPS` is made through a plugin. Plugins are independent applications which, similar to clients, use a network socket to communicate with the server. The advantages of this loose coupling are: * Plugins may be developed independently and in a arbitrary programming language. * A poorly written plugin does no crash the whole server. * Plugins may run on different machines to pull or push data. This allows to secure the access to the |appname| by a firewall. * Plugins may buffer data in case the server is temporary unavailable. * A |appname| client library for C++ and Python may be provided upon request allowing you to develop your own applications. .. _fig-architecture: .. figure:: media/architecture.* :width: 16cm Architecture of |appname|. .. _sec-deploy: Deployment ---------- The acquisition of data from other data centers is most likely done through a public interface reachable over the Internet. For instance seismic waveform data is commonly distributed via :term:`SeedLink` or :term:`ArcLink` servers while the tide gage community shares its data through a Web interface. For this center-to-center communication a plugin is launched on the receiving site to feed the :term:`CAPS` server. For the direct acquisition of data from a sensor the plugin has to run on the sensor station. At this point the diagram distinguishes two cases: In the first example the plugin sends the data directly to the :term:`CAPS` running at the data center. In the second case the data is send to a local CAPS server on the sensor station. From there it is fetch by the :ref:`caps2caps` plugin running at the data center. The options for possible deployments are illustrated in the figure below. The advantage of the second approach is: * **Better protection against data loss** - In case of a connectivity problem plugins may transient buffer data. Nevertheless main memory is limited and the buffered data may be lost e.g. because of an power outage. A local :term:`CAPS` will store observations to the hard drive for later retrieval. * **Direct client access** - A client may directly receive data from the sensor station. This is in particular useful for testing and validating the sensor readings during the station setup phase. The standard :term:`CAPS` client applications may be used in the field. * **Less packet overhead** - The :term:`CAPS` client protocol is more lightweight than the plugin protocol. Once connected each data stream is identified by a unique number. A client packet only consists of a two byte header followed by the data. .. _fig-deployment: .. figure:: media/deployment.* :width: 16cm Possible deployment of |appname| and its components. The ability to connect different :term:`CAPS` instances simplifies sharing of data. One protocol and one implementation is used for the sensor-to-center and center-to-center communication. In the same way multiple :term:`CAPS` instances may be operated in one data center on different hardware to create backups, establish redundancy or balance the server load.