Remote MT Protocol Peter Eriksson 16 Aug 1993 Status of this Memo This document attempts to define a protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. 1. INTRODUCTION The Remote MT Protocol (a.k.a., "rmt", a.k.a., the "RMT Protocol") provides a means for users to access remote tape devices without requiring them to login on the remote machine. The protocol described in this document is the same as used by the "rmt" Unix program, with the addition of a well known port to which remote users can connect to get RMT service. Authentication of remote users is NOT handled by this protocol in this version. 2. OVERVIEW This is a connection based application on TCP. A server listens for TCP connections on TCP port 411 (decimal). Once a connection is established, the servers reads lines of data which specifies the commands for manipulation of the magnetic tapes, performs the commands and then responds with a status indication. All command and reply codes are in ASCII. 3. NOTATIONAL CONVENTIONS In the protocol description that follows below the following notational conventions are used: <....> Denotes a field of information. [....] Denotes that what is contained within the brackets is optional and may or may not be present. \n Denotes an ASCII LineFeed (LF, code 10 (decimal)) character. 4. QUERY/RESPONSE FORMAT The server accepts simple one-letter ASCII commands (with optional arguments) of the form: [\n[\n][ and are ASCII decimal number, and is a sequence of bytes. If an unknown is received the server will drop the connection without returning an error reply. Some examples: O/dev/rmt8\n0\n L100\n1\n R5\n All responses are in ASCII and in one of two forms. Successful commands have responses of: A\n[] where is the ASCII representation of a decimal number, and [] may or may not be present, depending on the command this is a reply to. For example: A5\nHELLO A3\n Unsuccessful commands are responded to with: E\n\n where is a system dependant error number, and is a corresponding ASCII error message string. For example: E2\nNo such file or directory\n E6\nNo such device or address\n The protocol consists of the following commands: O\n\n Open the specified . The is an ASCII decimal value specifying the mode for opening it. It can be one of: 0 Read-Only 1 Write-Only 2 Read-and-Write C\n Close the currently open device. The argument is required, but currently ignored. Client implementations should use the same pathname as they used in the "O" command. L\n\n Perform a seek on the currently open device, if the device supports random access. The argument is a ASCII decimal number, whose meaning depends on the argument. can be one of the following: 0 Seek bytes from the beginning of the file open on the device. 1 Seek bytes relative the current position. 2 Seek bytes relative the end of the current file open. On a successful operation, the returned is the new position. W\n Write bytes to the currently open device. The bytes of to be written are sent immediately after the newline (\n) of this command. On a successful write, the returned is the actual number of bytes written. R\n Read up to bytes of data from the currently open device. If the read is successful, the is the number of bytes read and [] is the actual data read. I\n\n Perform a device control operation on the currently open device. can be one of: 0 Write EOF marks. 1 Forward space over EOF marks. 2 Space backwards over EOF marks. 3 Forward space over records. 4 Space backwards over records. 5 Rewind. is ignored. 6 Rewind and place device offline. is ignored. S\n Return the status of the currently open device On a successful operation, will contain the size of the system dependant binary structure returned in []. 5. SECURITY CONSIDERATIONS This protocol contains no provisions what so ever with regard to authenticating users using it. Currently all authentication will have to be done outside this protocol. 6. ACKNOWLEDGEMENTS Acknowledgement is given to Mike St. Johns, who's IDENT RFC I've used as a sort-of basis for this document. Acknowledgement is also given to W. Richard Stevens whose invaluable book 'Unix Network Programming' gave insight into the RMT protocol. Other sources for the information in this document is the 4.3BSD "rmt" program sources and manual pages. Author's Address Peter Eriksson Lysator ACS, c/o ISY Universitetet S-581 83 Linköping Sweden EMail: pen@lysator.liu.se