rmt - remote magtape protocol module
Rmt is a program used by the remote programs in manipulating a magnetic
tape drive through an interprocess communication connection. Rmt is
normally started up with an rexec(3N) or rcmd(3N) call.
The rmt program accepts requests specific to the manipulation of magnetic
tapes, performs the commands, then responds with a status indication.
All responses are in ASCII and in one of two forms. Successful commands
have responses of:
where number is an ASCII representation of a decimal number.
Unsuccessful commands are responded to with:
where error-number is one of the possible error numbers described in
intro(2), and error-message is the corresponding error string as printed
from a call to perror(3). The protocol is comprised of the following
commands (a space is present between each token):
Open the specified device using the indicated mode.
Device is a full pathname and mode is an ASCII
representation of a decimal number suitable for passing to
open(2). If a device had already been opened, it is
closed before a new open is performed.
Vversion#\n This command is sent by the client program to indicate the
version# of the 'librmt' library that the client program
is linked with. If rmt own protocol is the same or more
advanced than that of the client program, rmt will adjust
to the client program protocol and return the client
version# . However, if the client program version# is more
advanced than rmt own protocol version number then rmt
will return its actual version number and expect the
client program to adjust to rmt protocol. The returned
value is the ASCII representation of the version number.
Cdevice\n Close the currently open device. The device specified is
Perform an lseek(2) operation using the specified
parameters. The response value is that returned from the
Wcount\n Write data onto the open device. Rmt reads count bytes
from the connection, aborting if a premature end-of-file
is encountered. The response value is that returned from
the write(2) call.
Rcount\n Read count bytes of data from the open device. If count
exceeds the size of the data buffer (10 kilobytes), it is
truncated to the data buffer size. Rmt then performs the
requested read(2) and responds with Acount-read\n if the
read was successful; otherwise an error in the standard
format is returned. If the read was successful, the data
read is then sent.
Perform a MTIOTOP ioctl(2) command using the specified
parameters. The parameters are interpreted as the ASCII
representations of the decimal values to place in the
mt_op and mt_count fields of the structure used in the
ioctl call. The return value is the count parameter when
the operation is successful.
S\n Return the status of the open device, as obtained with a
MTIOCGET ioctl call. If the operation was successful, an
``ack'' is sent with the size of the status buffer, then
the status buffer is sent (in binary).
Q\n Perform a MTSCSIINQ ioctl(2) command. If the operation was
successful, an ``ack'' is sent with the size of the
inquiry buffer, then the inquiry buffer is sent (in
B\n Perform a MTIOCGETBLKSIZE ioctl(2) command. If the
operation was successful, an ``ack'' is sent with the size
of the block size buffer, then the block size buffer is
sent (in binary).
Z\n Perform a fstat(2) system call on the currently opened
device. If the operation was successful, an ``ack'' is
sent with the size of the ``stat'' structure, then the
actual ``stat'' structure is sent (in binary).
Any other command causes rmt to exit.
All responses are of the form described above. If rmt is invoked with an
argument, that argument will be treated as a file name and debug
information will be logged in that file.
rcmd(3N), rexec(3N), mtio(7),
People tempted to use this for a remote file access protocol are
PPPPaaaaggggeeee 3333 [ Back ]