Amidxtaped protocol
This page picks up where Amandad Service Protocol leaves off. Amidxtaped sends exactly one dump in response to a set of parameters on its control stream. To get another dump, start a new amidxtaped.
REQ
An amidxtaped REQ packet looks like:
SERVICE amidxtaped OPTIONS features=''features'';auth=''auth'';
All of the interesting specification of which data to send comes on the control connection, below.
REP
Amidxtaped sets up two streams in its REP packet:
CONNECT CTL ctlfd DATA datafd
the control connection is bidirectional, while the data connection only carries data from amidxtaped.
Control Connection
Note that when amidxtaped is started directly from inetd, the main socket becomes the control connection after the SECURITY line.
The control connection is a set of specifier lines, followed by an "END" line. All lines are terminated by "\r\n". Are you still asking why? Accept the insanity.
Not all specifiers must be given in any particular request. The available specifiers are:
- LABEL=label
- not a label, but a Tapelist Specification giving the files to be recovered
- FSF=fsf
- seek to this file before starting the recovery (ignored)
- HEADER
- prefix the data with an Amanda header (DISK_BLOCK_BYTES long)
- FEATURES=features
- reiterates the requester's feature-set (in case amidxtaped was started from inetd)
- DEVICE=device
- tape device (or changer) to restore from
- HOST=host
- host for this dump
- DISK=disk
- diskname for this dump
- DATESTAMP=datestamp
- datestamp for this dump
- CONFIG=config
- Amanda configuration to use
the list of specifiers is terminated by
END\r\n
or by any line that starts with a digit (.. good, you didn't ask why -- you're learning!). Any non-matchting lines will be ignored. Any lines after the terminating line are also ignored. Amrecover sends an invalid DATA-PATH specifier after END, presumably to illustrate this point.