SeedLink

Overview

The SeedLink protocol is a robust data transmission intended for use on the Internet or private circuits that support TCP/IP. The protocol is robust in that clients may disconnect and reconnect without losing data, the transmission is started where it ended. Requested data streams may be limited to specific networks, stations, locations and/or channels. All data packets are 512-byte Mini-SEED records. Enhancements to the SeedLink protocol supported by the DMC's server allow network and station codes to be wildcarded in addition to the location and channel codes.

Real-time Data from the IRIS DMC

The DMC runs a publicly accessible SeedLink server on the following host and port:

 

host: rtserve.iris.washington.edu
port: 18000 (default SeedLink port)

 

All open data that the DMC receives in real-time is available via this SeedLink server. Data arriving at the DMC more than 48 hours behind real-time are not exported via SeedLink.

 

Usage Restrictions
Users are welcome to any data available via the server as long as client actions do not inhibit our capability to deliver data to other users. In order to minimize the number of connections to the server it is highly recommended to use multi-station mode for collecting data from more than one station using a single connection. Keep alive (heartbeat) packets should not be sent at intervals less than 4 minutes. Please read our Expections policy below regarding service uptime.

 

Available Software

The following software is available from the DMC at http://www.iris.edu/pub/programs/SeedLink/:

 

libslink - A SeedLink client library written in C.

 

slink2orb - SeedLink to Antelope ORB client (licensed Antelope libraries are required).

 

slink2ew - SeedLink to Earthworm client. Windows binaries available.

 

slarchive - A SeedLink client that writes all received data to the local disk in user defined directory and file structures.

 

slinktool - Command line SeedLink client useful for data stream inspection and server testing.

 

ewexport_plugin - An Earthworm export process plugin (data source) for a seedlink server.

 

orbplugin - An Antelope ORB plugin (data source) for a seedlink server (licensed Antelope libraries are required).

 

Other SeedLink related software is available (or referenced by) the GEOFON SeisComP website

 

Example configurations

slink2orb - Antelope client configuration

 

Example command line that would go into the Processes table (Tbl) in your rtexec.pf:

 

slink2orb-DMC slink2orb -S state/slink2orb-DMC -pf slink2orb-DMC rtserve.iris.washington.edu $ORB

 

Do not forget to add slink2orb-DMC to the Run array (Arr) in your rtexec.pf too!

 

You need to define which channels you would like to receive in the parameter file of slink2orb.
Example contents of slink2orb-DMC.pf parameter file for use with the above instance of slink2orb is below.

 

slink2orb-DMC.pf:

stations &Arr{
#       NET_STA         [selectors]
        IU_ANMO         BH?  
        II_ADK          BH?
        TA_D15A         BH?
}
          

This example parameter file would select BH* channel data from the IU network station ANMO, the II network station BFO and the TA network station D15A.

 

For more details regarding channel selection and other slink2orb parameters consult the slink2orb man page and the default slink2orb.pf parameter file, both are distributed with Antelope

Protocol Details

The SeedLink protocol can be summarized as a simple, ASCII-based, data selection phase followed by the streaming of data packets from the server. SeedLink packets are composed of a small header followed by a 512-byte Mini-SEED record (data only SEED). The negotiation phase allows the client to request only specified data from the server for each selected data stream. A data stream is defined by a network and station code pair.

 

By utilizing sequence numbers for each packet in a data stream the SeedLink protocol allows for connections to be resumed, eliminating most data gaps. The ability to resume data streams is primarily dependant on how much data, time-wise, the remote SeedLink has in its buffer.

 

Special, out-of-band packets created by a seedlink server and recognized by libslink are used to communicate server details to clients and to implement keep-alive packet swapping. These special INFO packets are XML formatted data embedded in Mini-SEED comment records.

 

The protocol allows for two different modes of data transmission, uni-station and multi-station modes. Uni-station mode operates by transmitting a single data stream (data from a single station) through one network connection. In this mode the data stream does not need to be specified by the client as it is implied by the internet address and port. Multi-station mode operates by transmitting multiplexed data streams (data from multiple stations) through a single network connection. Almost all connections are negotiated as multi-station, even if only a single station is requested; uni-station mode, for most publicly accessible servers is deprecated.

 

SeedLink was originally created as the transport layer for the SeisComP package developed by GEOFON.

 

 

Expectations Regarding Real Time Data from the IRIS DMC

The IRIS DMC exists primarily to serve data needed for scientific studies.  As such, there is generally a weak case for delivering data in real time.  The DMC receives roughly seventy percent of its data through real time methods and this is the vast majority of data from permanent networks. Since the data received in real time can easily be made available in real time, the DMC does make all data received in real time, available through a SeedLink server with almost no latency added.  The DMC advocates for real time data availability since it is less costly to receive data at the DMC in real time rather than by delayed methods. It is also simple for the IRIS DMC to maintain outbound feeds of this data to the user community.

However, we do not have a mandate, nor is the DMC funded, to provide 24/7 real time data services.  As such interruptions in data flow may occur.  The DMC will attempt to remedy interruptions in its real time data feeds in a timely manner but we can guarantee neither the quality nor continuity in our real time data services.  All mission-oriented agencies should be aware of this limitation of real time data services from the DMC and plan accordingly.

To improve communication about real time data issues, the DMC manages a real time mailing list.  When problems with real time data flow are observed, messages will be posted to this list as the problems are discovered.  Solutions to the problems or information regarding resumption of real time data feeds will also be posted to this list.

You can subscribe to this list at
http://www.iris.washington.edu/mailman/listinfo/iris-rtfeeds