As explained on the ArcLink server documentation the server distributed with seiscomp3 does not know nothing about how to prepare the data products. Instead it uses the request-handler program to generate the products and just deliver the results prepared to the user. The server when started will start a couple of request-handlers (programs) that will communicate to the server using file descriptors. The server uses the file descriptor 62 to send requests to a request handler and reads status responses from file descriptor 63.
The communication between the server and the request handler is governed by an asynchronous protocol that is described in this documment.
The ArcLink server sends a request to a request handler in the following format:
USER <username> <password>
[INSTITUTION <any string>]
[LABEL <label>]
REQUEST <request_type> <req_id> <optional_attributes>
[one or more request lines...]
END
After receiving the request, the request handler can send responses to the server. The following responses are defined:
set line or volume status, where ref is "LINE n" or "VOLUME vol id" and status is one of the following:[[br]][[br]]
Status | Description |
---|---|
OK | request successfully processed, data available |
NODATA | no processing errors, but data not available |
WARN | processing errors, some downloadable data available |
ERROR | processing errors, no downloadable data available |
RETRY | temporarily no data available |
DENIED | access to data denied for the user |
CANCEL | processing cancelled (eg., by operator) |
Since the communication from the request handler to the ArcLink server is performed by file descriptors it is possible to test a request handler (provided on the seiscomp3 distribution) interactively by running a command similar to following:
python reqhandler -vvv 62>&0 63<&1 >reqhandler.log 2>&1
Now the program "reqhandler" waits for input from terminal and writes output to terminal as well. Additionally a logfile is written.
Let's type the following request:
USER somebody@gfz-potsdam.de
REQUEST WAVEFORM 123 format=MSEED
2008,2,21,2,50,0 2008,2,21,3,10,0 EE MTSE BHZ .
2008,2,21,2,50,0 2008,2,21,3,10,0 GE WLF BHZ .
END
The log might look similar to following:
01 [None] > USER somebody@gfz-potsdam.de
02 [None] > REQUEST WAVEFORM 123 format=MSEED
03 [123] new WAVEFORM request from somebody@gfz-potsdam.de, None
04 [123] > 2008,2,21,2,50,0 2008,2,21,3,10,0 EE MTSE BHZ .
05 [123] < STATUS LINE 0 PROCESSING GFZ
06 [123] > 2008,2,21,2,50,0 2008,2,21,3,10,0 GE WLF BHZ .
07 [123] < STATUS LINE 0 SIZE 43008
08 [123] > END
09 [123] < STATUS LINE 1 PROCESSING GFZ
10 [123] < STATUS LINE 0 OK
11 [123] < STATUS LINE 1 MESSAGE size not known
12 [123] < STATUS LINE 1 OK
13 [123] < STATUS VOLUME GFZ SIZE 73728
14 [123] < STATUS VOLUME GFZ OK
15 [123] < END
Note that the status responses are asynchronous.
Minimal status response when data is available:
STATUS LINE 0 PROCESSING GFZ
STATUS LINE 1 PROCESSING GFZ
STATUS LINE 0 OK
STATUS LINE 1 OK
STATUS VOLUME GFZ SIZE 73728
STATUS VOLUME GFZ OK
END
Minimal status response (and an optional error message) when data is not available:
STATUS LINE 0 PROCESSING GFZ
STATUS LINE 1 PROCESSING GFZ
STATUS LINE 0 NODATA
STATUS LINE 1 NODATA
STATUS VOLUME GFZ NODATA
MESSAGE optional error message
END