User's Guide
and
Protocol Specification
Revision/Update Information: MG-RTEFTP-TM-005
Operating System and Version: RT-11 V5.5 or higher
Software Version: Y01.36
This manual describes the use of the RT-11 Ethernet File Transfer Program, RTEFTP. In addition, it documents the protocol and the internal structures employed by the program.
Related documents:
This manual is intended for RT-11 system users who plan on installing and using RTEFTP on their system and for system programmers who wish to understand the operation of the program and the protocol so that they might implement a version for their favorite operating system.Note to developers: If you plan on developing an implementation for your system, I would be very interested in knowing about it and would be willing to provide what assistance I can.
I am also interested in, and would appreciate reports of, any errors found in this document or in the program. I can be reached at gentry@zk3.dec.com and my US Mailing address is:
Megan Gentry
Compaq Computer Corporation
110 Spitbrook Rd. ZKO3-2/T43
Nashua, NH 03062
(603) 884 1055
(603) 884 0554Finally, it is important to point out that although both the protocol and the program were designed and implemented initially for use under RT-11, and that most of this manual is targetted toward its use on RT-11, I endeavored to design the protocol such that it was as generic as possible.
The RT-11 Ethernet File Transfer Program, RTEFTP, is a general purpose utility designed to allow the user of an RT-11 system to transfer files to and from other RT-11 systems in a local area network or to make files on their system available for access by users on other RT-11 systems on that network.RTEFTP is designed for use under an XM Monitor with timer support. It can be run as a background, system, or foreground job. It may also be run under the virtual background executive, VBGEXE.
RTEFTP employs a positive-acknowledgement transaction-based protocol with error checking and timeout recovery. It may be in operation over the Ethernet concurrent with other Ethernet applications
All RT-11 devices which are defined as RT-11 file-structured, but not special directory structured, are supported. Magtapes are not supported.
At this time, RTEFTP provides no conversion of file formats. All files are transferred in image mode, block for block (with a block consisting of 512. bytes).
The RT-11 Ethernet File Transfer Program (RTEFTP) is installed by simply copying RTEFTP.SAV to the system volume, as in the following command..COPY ddn:RTEFTP.SAV SY:Apply any applicable desired and/or required customization patches.
In order to run RTEFTP, you must first ensure that you are:
- Running an RT11 Extended Memory (XM) Monitor
- The XM Monitor must have timer support
- The appropriate Ethernet handler (NC, NQ or NU) must be loaded
If any of the above criteria are not met, RTEFTP will be unable to run.
RTEFTP is used in one of two ways -- As an unattended server or as a simple utility. As an unattended server, it typically runs as a system or foreground job, providing file access to remote users while other activities are performed in the background. As a simple utility it is possible to get a file from or put a file to a machine on the local area network, without having to enable remote access. There is no requirement, however, that it run as a foreground or system job when used as a server, or that it run in the background as a simple utility.
To run RTEFTP in the background, issue one of the following commands:
- .RTEFTP
- The program is executed via CCL from SY:
- .R RTEFTP
- The program is executed via KMON from SY:
- .V RTEFTP
- The program is executed via KMON from SY: under VBGEXE (V5.6)
- .RUN RTEFTP
- The program is executed via KMON from the default device, DK
- .RUN ddn:RTEFTP
- The program is executed via KMON from device ddn:
In order to run RTEFTP as a system or foreground job, it is necessary to have it execute in the VBGEXE context. First, ensure that both VBGEXE.SAV and RTEFTP.SAV reside on the system volume, then you may issue the following command:
.{F|S}RUN SY:VBGEXE.SAV/NAME:RTEFTP/BUFFER:250.After RTEFTP has been started, additional commands are required to perform file transfers, establish remote access, or to establish access control lists.
To terminate RTEFTP, enter the command EXIT or type <CTRL/C> twice.
RTEFTP employs a least-unambiguous command scanner. Its syntax is modelled after that of RT-11 DCL and DECnet. Commands to RTEFTP consist of a single word followed by one or more optional or required arguments. If a command is incomplete, RTEFTP will prompt for the missing required elements.
The BROADCAST command is used to send a message to
one or more participating nodes.
__________________________________________________________________
FORMAT
BROADCAST destination "text"
__________________________________________________________________
DESTINATION
ALL
Sends the message specified by 'text' to all
RTEFTP nodes whether they are enabled for remote
access or not.
node_name
Sends the message specified by 'text' to the
specified node. The node must be enabled for
remote access and show up in the remote node
list (see SHOW NODES).
__________________________________________________________________
TEXT
Specifies the text to be sent. Quotes are required
when the command is specified in one line. If
quotes are not included, only the first word of
the text will be sent.
The CLEAR command is used to reset or disable
certain program information or operating
characteristics.
__________________________________________________________________
FORMAT
CLEAR option
__________________________________________________________________
OPTIONS
ACCESS [dev:filnam.typ]
Clears the contents of the access control list,
allowing unrestricted access to local devices and
files if remote access is enabled.
Optionally, you may remove one or more access
control list entries by specifying the appropriate
file specification.
BROADCAST
Disables reception of broadcast messages.
LOG
Disables local event logging.
NAME
Clears the local node name, disabling remote
access and timebase service.
NODES [node_name]
Clears the local list of remote nodes known to be
accepting remote access. This table is rebuilt
as Node_Identification control packets are
received from nodes which have enabled remote
access (see SET NAME).
Optionally, you may remove the remote node
list entry for a specific node by specifying
its name.
TIME
Disables timebase service. All participating nodes
will resume deriving their date and time locally.
The COPY command initiates a file transfer from
the local node to a remote node, or from a remote
node to the local node.
__________________________________________________________________
FORMAT
COPY[/qualifiers...] [node_name::]input_file_spec [node_name::]output_file_spec
__________________________________________________________________
QUALIFIERS
QUEUE
Initiates a transfer and returns to the command
prompt, allowing further commands to be issued.
DEVICE
Indicates a non-file-structured access of a local
device. Required if output specification is local.
__________________________________________________________________
DESCRIPTION
A node_name must be specified for either the input
or output file, but not both. Only nodes which
have enabled remote access (see SET NAME) may be
specified. Wildcards are not yet supported for either
input or output.
Since the portion of the command string following
the '::' on input or output is passed to the
remote node for parsing, it must adhere to any
device or file naming rules applicable for that
operating system.
When RTEFTP is first started, it has no capability
of performing file transfers until it has
knowledge of at least one other node on the
Ethernet running RTEFTP. As each node is enabled
for remote access (see SET NAME), it begins
sending out a message which informs all RTEFTP
participating nodes of its existence.
File transfers may only be performed with nodes
which have had remote access enabled, but it is
not required that the local node be enabled for
remote access to initiate a file transfer.
The user has full access rights to local devices
and filenames while access rights to devices and
filenames on a remote node are verified on that
node.
The DELAY command causes RTEFTP to wait for the
specified node to become available for remote
access before returning to the command prompt.
__________________________________________________________________
FORMAT
DELAY node_name
__________________________________________________________________
DESCRIPTION
This command is particularly useful when executed
from within an indirect command file, since
further file processing (generally COPY commands)
will not proceed until the required node is
available.
If the specified node does not become available
in one minute, the program returns to the command
prompt.
The DIRECTORY command obtains and displays the
directory of a volume mounted on a remote node.
__________________________________________________________________
FORMAT
DIRECTORY node_name::file_specs[,...]
__________________________________________________________________
DESCRIPTION
Since the portion of the command string following
the '::' is passed to the remote node and parsed
there, it must adhere to any device and file
naming rules applicable on that machine.
For RT-11 nodes, the file_specification may consist
of one device specification and up to 8(10) file names
separated by commas, with full wildcarding allowed.
If no device is specified, the default device, DK:
is used.
The EXIT command is used to terminate program
execution.
__________________________________________________________________
FORMAT
EXIT
__________________________________________________________________
DESCRIPTION
If there are any currently active circuits,
further remote access is disabled while the user
is queried whether the active circuits should be
aborted. If not, remote access is re-enabled and
the program returns to the command prompt to await
further commands.
If remote access has been enabled, a message is
sent to inform all participating nodes that the
local node is becoming unavailable.
The HELP command is used to obtain information on
the use of RTEFTP commands.
__________________________________________________________________
FORMAT
HELP [topic]
__________________________________________________________________
DESCRIPTION
where topic is the name of the command for
which help is desired. If not specified, the
program will list all commands for which help
is available. If the topic specified is *, the
program will list help for all commands for which
help is available.
The SET command is used to set various operating
characteristics of the program.
__________________________________________________________________
FORMAT
SET option
__________________________________________________________________
OPTIONS
ACCESS dev:filnam.typ[/qualifier...]
Adds the specified device and file to the access
control list, setting access as specified in the
options. 'dev' may be any known device or logical
on the local node. 'filnam.typ' may contain
wilcard characters. 'option' is of one of the
following:
Table 2-1 Access Rights Options
----------------------------------------------
Qualifier Meaning
----------------------------------------------
D Allows non-file-structured access
E Access is excluded
L Access by explicit device name,
no logical to physical translation
performed
R Read access is allowed, directory
access implied
W Write access is allowed, directory
access implied
----------------------------------------------
BROADCAST
Enables reception of broadcast messages.
LOG
Enables event logging. Event logging is useful to
track node available/unavailable events as well as
remote accesses to devices and files on the local
machine. It also reports access violations if an
access control list has been established.
NAME node_name
Establishes the name by which the local node is
known to participating nodes, enabling remote
access.
TIME
Establishes the local node as the timebase for
all participating nodes. This service is useful
in coordinating the dates and times on a series
of machines. A node may be enabled as the timebase
only if it is also enabled for remote access, and
only one participating node may be enabled as the
timebase at a time.
Ensure that your local node has the correct date
and time before issuing this command, otherwise
all participating nodes will have incorrect dates
and times.
The SHOW command is used to displays the settings
of certain program information.
__________________________________________________________________
FORMAT
SHOW option
__________________________________________________________________
OPTIONS
ACCESS
Displays the current access rights list.
CHARACTERISTICS
Lists the operating characteristics, including
protocol version number, number of receive buffers,
number of virtual circuits, and number
of active circuits.
CIRCUITS
Lists the status of all virtual circuits,
specifying type of connection and including
information relative to the connection.
For circuits performing file transfers, lists
direction of transfer, file name, file size and
current block.
For circuits performing directories, lists device
and file specifications from DIRECTORY command.
NODES
Lists information on all nodes known to be enabled
for remote access, including node name, Ethernet
address and settings of various operating flags.
The following section illustrates a typical setup and usage of the RTEFTP Ethernet file transfer program. In the example, RTEFTP.SAV resides on the system volume and will run in the background. User entered text is italicized.Once RTEFTP has been installed on the system volume, it may be loaded and execution begun by issuing the following command at the KMON prompt:
.RTEFTPRTEFTP responds with 'RTEFTP>' at the left margin to indicate its readiness to accept commands.
RTEFTP> SET LOGThe user will now be informed as nodes become available for remote access or become unavailable.
RTEFTP> SET ACCESS SY:/R/LAn access control list is established, restricting remote access to this machine to read access of all files on logical device SY:. Access to this device must be explicit, no device translation will occur.
RTEFTP> SET NAME ARISIAThe local node name is established as ARISIA, enabling remote access. All participating nodes will note the fact that ARISIA is now available for remote access.
RTEFTP> COPY A.B HELMTH::SY:A.BCauses the local file DK:A.B to be transferred to node HELMTH and placed in the remote file SY:A.B.
RTEFTP> COPY/QUEUE BREADB::DU1:C.D C.D>RTEFTP>
Causes the remote file DU1:C.D on node BREADB to be transferred to the local file DK:C.D, but the program returns immediately to the command prompt, signifying its readiness to accept further commands. The user will be informed when the transfer completes. The status of the transfer can be checked through use of SHOW CIRCUITS.
The following chapter describes the internal data structures used in the RT-11 implementation of the RTEFTP file transfer program.In describing data structures, the form used is to provide a graphic representation of the data structure as it is actually organized, along with the names for the various fields within it. Then, for each field, its size and contents are described. The size is in bytes and is indicated by being enclosed in parenthesis. The field will either be a binary value, indicated by 'B', or a bit mask, indicated by 'BM'. Some fields can be both.
The timer IDs were designed to be a unique number which encodes the virtual circuit number as well as the timer type. Since issuing a 'cancel mark-time' request (an RT-11 specific operation) with an ID of 0 cancels all outstanding timer requests, the lowest timer number defined is 1. This ensures that we never attempt to cancel timers using an ID of 0 (this could occur only in processing circuit 0 timers).A Timer ID value is formatted as follows:
15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0| CIRCUIT | TIMER | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ struct timerid { unsigned short tid_timer:8; /* Timer number */ unsigned short tid_vcirc:7: /* Virtual Circuit Number */ unsigned short tid_mbz:1; /* must be zero */ };
- <15>
- must be zero
- CIRCUIT
- the virtual circuit number
The architectural limit for the circuit number is 1778 (12710), though the practical limit under RT-11 is 7. This limit is used to avoid excessive use of low memory through use of the .CDFN programmed request (an RT-11 specific system call).
- TIMER
- timer number
The architectural limit for the timer number is 3778 (25510).
Timer 1 is the five-second node identification timer. When remote access has been enabled (refer to SET NAME) and this timer expires, a Node_Identification control packet is sent to the RTEFTP multicast address, notifying all participating nodes. The timer is then reposted.Timer 1 is processed only by virtual circuit 0.
Timer 2 is the one-second remote node list processing timer. When it expires, the remote node list is scanned and any entry which has timed-out is removed and the node it defined is reported as unavailable. The timer is then reposted.Timer 2 is processed only by virtual circuit 0.
Timer 3 is the two-second packet retransmit timer. If the response to a packet is not received by the time this timer expires, the last packet transmitted for the indicated virtual circuit is retransmitted and the timer is reposted.Timer 3 is processed by all virtual circuits.
Timer 4 is the ten-second connection timer. If the response to a packet is not received by the time this timer expires, the remote node involved in a transfer on the indicated virtual circuit is assumed to have become unavailable and the connection is terminated.Timer 4 is processed by all virtual circuits.
The 208 (1610) channels provided by RT-11, 0 - 178 (0 - 1510) are divided by use into file access, network access and temporary-use or utility channels.
Eight channels, 0 - 7, are available for file access. This number is tied to the practical limit for the number of virtual circuits, and there is a direct mapping between virtual circuit number and file access channel.The file access channel number can be obtained by extracting it from a timer ID or from within a virtual circuit definition block.
Two channels, 148 and 158 (1210 and 1310), are used for network access, one for synchronous traffic and one for asynchronous traffic. Asynchronous requests are those which RTEFTP issues, not worrying about when they might complete. RTEFTP waits for synchronous requests to complete before it continues.Two separate channels are used because of the way RT-11 works. Any synchronous requests issued on a channel on which asynchronous requests are outstanding might never complete, especially of such asynchronous requests issue additional requests from completion routines.
One channel (168) is reserved for use by support routines so long as such use is only for the duration of the routine. The channel must be available for use when the routine completes.An example of this use is the RTEFTP routine CVLTOP, which converts RT-11 logical device names to physical device names. This routine uses .CSTAT, which requires a channel to be opened to the specified device.
One channel, 178, is reserved for use by RT-11 and unused by RTEFTP at the present time.
There is a table of pointers to the allocated receive buffers, a byte which indicates how many buffers are available and a byte which is used as an index into the table for retrieving the pointer to the next receive buffer to be processed, updated as each receive buffer is processed.The program is built to handle a maximum of eight asynchronous receive buffers, but only two are built into the image. Additional buffers are dynamically allocated from available memory at run-time. Receive buffers are of the form described here.
A customization patch allows you to specify the maximum number of receive buffers for which RTEFTP will attempt to reserved space.
Receive buffer sequencing is performed via completion routines.
Virtual Circuits are data structures which contain all the information required in order to accomplish some network operation such as a file transfer or a directory.There is a table which contains pointers to the available virtual circuit definition blocks. There is also a count of the number of available virtual circuits. Each incoming message has a byte which indicates the number of the circuit to which the message has been addressed. This value is used as an index into the table for retreiving the pointer to the virtual circuit which will process the message.
The program is built to handle a maximum of eight virtual circuits, but only two are built into the image. Additional circuits are dynamically allocated from available memory at run-time. One transmit buffer is defined within each virtual circuit.
A customization patch allows you to specify the maximum number of virtual circuits RTEFTP will attempt to make available.
The structure of a virtual circuit definition block is defined as follows:+-----+-----+-----+-----+-----+-----+-----+-----+ | AFG | ORG | STA | CFG | LCN | RCN | PAD | DYN | ... +-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+--~--+-----+--~--+ ...| HAN | DBK | FSZ | BLK | XSZ | XBF | DBS | DBF | +-----+-----+-----+-----+-----+--~--+-----+--~--+ struct vcircuit { unsigned char vc_afg; /* Circuit allocation flag */ unsigned char vc_org; /* Circuit origination info */ char * vc_sta; /* Pointer to current state */ unsigned short vc_cfg; /* Circuit flags */ unsigned char vc_lcn; /* Local circuit number */ unsigned char vc_rcn; /* Remote circuit number */ unsigned char vc_pad[6]; /* Partner (remote) Ethernet address */ char * vc_dyn; /* Pointer to dynamic memory */ char * vc_han; /* Pointer to fetched handler */ unsigned short vc_dbk[4]; /* RT-11 DBLK for file access */ unsigned short vc_fsz; /* File size */ unsigned short vc_blk; /* Block number */ unsigned short vc_xsz; /* Transmit size */ unsigned char vc_xbf[BF.SIZ]; /* Transmit buffer */ unsigned short vc_dbs; /* Double-buffering status */ unsigned char vc_dbf[512]; /* Read-ahead/write-behind buffer */ };
- AFG (1) : B
- a byte containing the virtual circuit allocation flag. This byte contains a -1 if the circuit is available. The allocation of a circuit should be done using an atomic operation (such as an INCB on the PDP-11) in order to avoid a race between circuit allocation from mainline code and circuit allocation from completion code.
- ORG (1) : BM
- a byte mask containing the set of flags indicating the type of connection, as follows:
7 6 5 4 3 2 1 0 +-----+-----+-----+-----+-----+-----+-----+-----+ | LOC | CON | MODE | TYPE | +-----+-----+-----+-----+-----+-----+-----+-----+ struct vcorg { unsigned char org_type:4; unsigned char org_mode:2; unsigned char org_con:1; unsigned char org_loc:1; };
- LOC
- indicates a locally-initiated transfer
- CON
- indicates a two-way connection has been established
- MODE
- indicates connection modifiers, from initial connect packet
- TYPE
- indicates connection type, from initial connect packet
- STA (2) : B
- a word containing a pointer to the current state definition block in the finite state machine.
- CFG (2) : B | BM
- a word containing the circuit flags. Contents are operation-dependant.
- LCN (1) : B
- a byte containing the local circuit number. On RT-11, this maps directly to the file access channel number.
- RCN (1) : B
- a byte containing the remote circuit number. This is used to verify unique circuit allocation when establishing a connection for an incoming request.
- PAD (6) : B
- six bytes containing the Ethernet physical station address of the remote node. Used for packet validation.
- DYN (2) : B
- a word pointing to a region of dynamically-allocated memory which is used to store operation-specific data for the circuit. Zero indicates none.
- HAN (2) : B
- a word containing a pointer to a region of dynamically-allocated memory used to fetch a handler for use by a circuit. Zero indicates none.
- DBK (8) : B
- four words containing the file specification in Radix-50.
- FSZ (2) : B
- a word containing the size of the file being accessed. Zero until known.
- BLK (2) : B
- a word containing the number of the block being accessed during a file transfer. Contains the record number during a directory operation.
- XSZ (2) : B
- a word containing the size of the packet contained in the transmit buffer, used for packet retransmit.
- XBF (BF.SIZ) : B
- the asynchronous transmit buffer.
- DBS (2) : B
- a word containing the status reported following the posting of the last I/O request for the file access channel associated with this circuit. The MSB indicates an error occurred, the low byte reflects the contents of byte 52 (the RT-11 User Error Byte) following the error.
- DBF (512) : B
- the one-block read-ahead or write-behind buffer used in double-buffering disk operations.
The finite state machine operates through a series of states. Each state consists of a series of event definitions, each specifying an event that might occur in that state, the name of the routine to execute when the event occurs, and a specification for the next state to be entered.
The state definition block consists of a series of event definition blocks, terminated in a word which contains a zero. The structure is as follows:+------------------+------------------+ +-----+ | Event Definition | Event Definition | ... | 0 | +------------------+------------------+ +-----+There may be any number of event definition blocks in a given state, but it must be kept in mind that the more events in a given state, the longer it will take to process a given event due to the sequential scan of a given state table searching for a matching event.
The structure of an event definition block is as follows:+-------+---------+-----------+ | Event | Process | New State | +-------+---------+-----------+
- EVENT (2) : B
- a word containing either the complete timer ID (for timer completion routines), or the expected packet code (for receiver completion routines) in the low-order byte. Zero indicates the end of the current state definition block.
- PROCESS (2) : B
- a word containing the address of the routine to be used to process the event.
- NEW STATE (2) : B
- a word containing the address of the state definition block to which the finite state machine will transition following processing of this event. Contains zero if no transition is to occur, the state machine remains in the same state.
In actuality, this address is loaded into the virtual circuit prior to executing the event processing routine. This is done so that the event processing routine may redirect the state machine to a different state based on the outcome of the processing of the event.
tbs
The access control list is a linked list containing entries which specify the devices, files and types of remote access which are to be allowed or disallowed by the local node.Access control list entries are added to this list through the use of the SET ACCESS command.
Access control list entries are removed from this list through the use of the CLEAR ACCESS command.
The contents of the list can be viewed through the use of the SHOW ACCESS command.
The structure of an access control list entry is as follows:+-----+-----+-----+-----+-----+-----+-----+ | LNK | FLG | res | DEV | FIL | TYP | PSW | +-----+-----+-----+-----+-----+-----+-----+ struct acl_entry { struct acl_entry * acl_lnk; /* Pointer to next ACL entry */ unsigned char acl_flg; /* ACL flags */ unsigned char acl_reserved; /* reserved */ unsigned short acl_dev; /* RT-11 Device (1 word Rad50) */ unsigned short acl_fil[2]; /* RT-11 Filename (2 words Rad50) */ unsigned short acl_typ; /* RT-11 Filetype (1 word Rad50) */ unsigned short acl_psw[2]; /* <future> Password */ };
- LNK (2) : B
- a word containing a pointer to the next access control list entry. This word will contain a zero if there are no further entries.
- FLG (1) : BM
- a byte containing the set of flags which indicate the access type for the device and file specified.
7 6 5 4 3 2 1 0 +-----+-----+-----+-----+-----+-----+-----+-----+ | NFS | EXP | EXC | DIR | PSW | res | WRI | REA | +-----+-----+-----+-----+-----+-----+-----+-----+
- NFS
- indicates non-file-structured access is allowed
- EXP
- indicates explicit device access allowed (reference to the device must be by use of specified name)
- EXC
- indicates access is not allowed
- DIR
- indicates directory may be obtained for this device
- PSW
- indicates password is required for access (future)
- res
- reserved for future use
- WRI
- indicates write access is allowed
- REA
- indicates read access is allowed
- res (1) : B
- undefined and reserved for future use.
- DEV (2) : B
- a word containing the Radix-50 representation of a three-character device name.
- FIL (4) : B
- two words containing the Radix-50 representation of a six-character file name.
- TYP (2) : B
- a word containing the Radix-50 representation of a three-character file type.
- PSW (4) : B <future>
- two words containing the Radix-50 representation of a six-character password, possibly encoded, used for access verification.
The remote node list is a linked list containing entries which specify the remote nodes which have enabled remote access.Entries are added to this list through receipt of a Node_Identification control packet.
Entries are removed from this list during processing of the remote node list processing timer.
The contents of the list can be viewed through the use of the SHOW NODE command.
The Remote Node List Entry is a data structure which contains all information relating to a single node on the network which has enabled remote access (refer to SET NAME)
The format of a Remote Node List Entry is as follows:+-----+-----+-----+-----+-----+-----+ | LNK | TMO | FLG | NAM | FSY | ADR | +-----+-----+-----+-----+-----+-----+ struct ndl_entry { struct ndl_entry * nd_lnk; /* Pointer to next list entry */ unsigned char nd_tmo; /* Timeout for this entry in seconds */ unsigned char nd_flg; /* Node definition flags */ unsigned char nd_nam[7]; /* Node name */ unsigned char nd_fsy; /* File system */ unsigned char nd_add[6]; /* Ethernet station physical address */ };
- LNK (2) : B
- a word containing a pointer to the the next Remote Node List Entry. In Node_Identification control packets, this word is unused and reserved. Zero indicates end of list.
- TMO (1) : B
- a byte which contains the timeout value, in seconds. If this count reaches zero before another Node_Identification control packet has been received from the node defined by this entry, the node is assumed to have become unavailable and the entry is removed from the remote node list.
- FLG (1) : BM
- a byte containing the node service flags, as follows:
7 6 5 4 3 2 1 0 +-----+-----+-----+-----+-----+-----+-----+-----+ | RAC | LOG | TSV | NOB | reserved | +-----+-----+-----+-----+-----+-----+-----+-----+ struct ndflg { unsigned char fg_res:4; /* reserved */ unsigned char fg_nob:1; /* No Broadcast */ unsigned char fg_tsv:1; /* Time server */ unsigned char fg_log:1; /* Node logs events */ unsigned char fg_rac:1; /* Remote access enabled */ };
- RAC
- indicates node accepts remote access
- LOG
- indicates node is logging transactions
- TSV
- indicates node provides timebase service
- NOB
- indicates node does not want to receive broadcast messages
- NAM (7) : B
- a six byte field containing the node name in ASCII, padded with spaces to fill 6 bytes, and a byte containing <200>.
- FSY (1) : BM
- a byte which indicates the file system in use on the node, defined as follows:
7 6 5 4 3 2 1 0 +-----+-----+-----+-----+-----+-----+-----+-----+ | CUS | TYPE | LEVEL | +-----+-----+-----+-----+-----+-----+-----+-----+ struct ndfsy { unsigned char fs_level:3; /* File system level */ unsigned char fs_type:4; /* File system type */ unsigned char fs_cust:1; /* Customer/CSS file system */ };
- CUS
- indicates customer/CSS file system
- TYPE
- indicates file system type
- LEVEL
- indicates file system level
- ADR (6) : B
- the six bytes containing the Ethernet station physical address of the node.
An RTEFTP receive or transmit buffer consists of four parts: The header required by RT-11 for Ethernet operations, the header required by the Ethernet for all frames, the RTEFTP packet header and the RTEFTP packet.The four parts are concatenated into one contiguous section in memory, with the format as follows:
+-----------------------+ | RT-11 buffer header | +-----------------------+ | Ethernet frame header | +-----------------------+ | RTEFTP packet header | +-----------------------+ | RTEFTP packet | +-----------------------+
The format of the standard RT-11 Ethernet buffer header is as follows:+--------------+--------------+--------+ | MAJOR_STATUS | MINOR_STATUS | LENGTH | +--------------+--------------+--------+ struct rtethbufhdr { unsigned char bh_maj; /* Status code returned by RT-11 */ unsigned char bh_min; /* Status subcode returned by RT-11 */ unsigned short bh_len; /* Received frame size */ };
- MAJOR_STATUS (1) : B
- a byte which contains the major status returned from an Ethernet request. Refer to the RT-11 documentation.
- MINOR_STATUS (1) : B
- a byte which contains the minor status returned from an Ethernet request. Refer to the RT-11 documentation.
- LENGTH (2) : B
- a word which indicates the actual size, in bytes, of a received frame. Undefined for transmit requests.
The format of the Ethernet frame header is as follows:+-----+-----+----+ | DST | SRC | PT | +-----+-----+----+ struct ethhdr { unsigned char eh_dst[6]; /* Destination Ethernet address */ unsigned char eh_src[6]; /* Source Ethernet address */ unsigned char eh_pt[2]; /* Protocol type */ };
- DST (6) : B
- the 6 bytes which specify the destination Ethernet address. For Node_Identification and Broadcast control packets the destination is the multicast address, Hex AB-00-04-00-60-06. All other packets use Ethernet station physical addresses.
A customization patch allows specification of a different multicast address to be used.
- SRC (6) : B
- the 6 bytes which specify the source Ethernet address. For transmit, normally specified as Hex 00-00-00-00-00-00, which causes the local Ethernet station physical address to be used. On receive, indicates the station physical address of the node which sent the packet.
- PT (2) : B
- the 2 bytes which specify the Ethernet protocol type. Hex 60-06 for RTEFTP protocol.
A customization patch allows specification of a different protocol type to be used.
The format of an RTEFTP packet header is as follows:+------+--------+----------+-----+-----+ | CODE | STATUS | PROTOCOL | ICN | OCN | +------+--------+----------+-----+-----+ struct msghdr { unsigned char mh_cod; /* Message code */ unsigned char mh_sta; /* Message status (return code */ unsigned short mh_pro; /* RTEFTP Protocol version (Rad50) */ unsigned char mh_icn; /* Incoming (local) circuit number */ unsigned char mh_ocn; /* Outgoing (remote) circuit number */ };
- CODE (1) : BM
- a byte containing the set of flags which indicate the type of RTEFTP packet.
7 6 5 4 3 2 1 0 +-----+-----+-----+-----+-----+-----+-----+-----+ | NAK | RES | MODIFIERS | TYPE | +-----+-----+-----+-----+-----+-----+-----+-----+ struct mhcod { unsigned char mc_typ:4; /* Message type */ unsigned char mc_mod:2; /* Modifier */ unsigned char mc_res:1; /* Response (=1) */ unsigned char mc_nak:1; /* Negative Acknowledgement (=1) */ };
- NAK
- indicates a negative acknowledgement when set, indicates a positive acknowledgement when reset. Valid only in a response packet.
- RES
- indicates a response packet when set, indicates a message packet when reset.
- MODIFIERS
- indicates the packet type modifier
- TYPE
- indicates the packet type
All combinations of NAK and RES bits are valid with the exception of NAK set and RES reset. This pattern is invalid and reserved.
- STATUS (1) : B
- a byte containing the status code returned with NAK responses.
- PROTOCOL (2) : B
- indicates the RTEFTP protocol version information in Radix-50. It is a three character string of the form 'x.y' where 'x' is the major protocol version number and 'y' is the minor protocol version number.
For the current release, this word contains Radix-50 '1.3'
- ICN (1) : B
- indicates the incoming virtual circuit number (0-12710). Used to indicate which virtual circuit is to process this packet. A negative value is used by the node initiating the transfer in order to request allocation of a virtual circuit.
It should be noted that in a packet to be transmitted, this byte contains the number of the virtual circuit on the partner's node which is to receive the packet. In a received packet, this byte contains the number of the virtual circuit on the local node to which this packet should be directed.
- OCN (1) : B
- indicates the outgoing virtual circuit number (0-12710). Used to indicate the number of the virtual circuit to which responses are to be sent.
It should be noted that in a packet to be transmitted, this byte contains the number of the virtual circuit on the local machine which is sending the packet. In a received packet, this byte contains the number of the virtual circuit on the remote node from which this packet was sent.
The contents of the 'payload' portion of an RTEFTP message packet are variable, as is the size of the packet:+------ ~ ------+ | RTEFTP packet | +------ ~ ------+RTEFTP packet (variable) : B The actual RTEFTP packet. Contains data appropriate for the packet type specified in the packet header.
In each of the following sections, only the contents of the packet beyond the packet header are described. The contents of the code byte in the packet header is the logical OR of the packet type and packet type modifier specified.Packet turn-around is accomplished by moving the source address field in the received packet to the destination address field, zeroing the source address field (which, under RT-11, causes the station physical address to be used), swapping the incoming and outgoing circuit number fields and either ACKing (setting the RES bit) or NAKing (setting the NAK and RES bits) the packet code. The frame may then be transmitted. The minimum Ethernet frame size is always used for responses as they are always shorter than the minimally-sized RTEFTP packet.
Control packets are used to distribute information to or solicit information from participating nodes on the network.
The Node_Identification control packet is used to identify a node which has enabled remote access to participating nodes on the network.
The format of the Node_Identifcation control packet is as follows:(Type = 0, Modifiers = 00) +-----------+------+------+ | NODE_INFO | DATE | TIME | +-----------+------+------+
- NODE_INFO (nnn) : B
- contains the node definition block for the node which sent the Node_Identification control packet.
- DATE (2) : B
- a word containing the current date, in RT-11 format. Refer to the RT-11 documentation.
struct rtdate { unsigned short da_year:5; /* Years since 1972 */ unsigned short da_day:5; /* Day of month */ unsigned short da_mon:4; /* Month of year */ unsigned short da_epoch:2; /* RT-11 Epoch */ };
- TIME (4) : B
- two words containing the current time, in RT-11 ticks-past-midnight format. Refer to the RT-11 documentation.
All nodes enabled for remote access send out periodic Node_Identification packets.
The Broadcast control packet is used to send messages to one or all nodes on the network which are using the RTEFTP protocol.
The format of the Broadcast control packet is as follows:(Type = 0, Modifiers = 208) +-----+-----+ | TLN | TBF | +-----+-----+ struct dbroadcast { unsigned char br_tln; /* Text length (0 - 25410) */ unsigned char br_tbf[255]; /* Text (nul-terminated) */ };
- TLN (1) : B
- a byte which contains the message length (0-25410) in bytes.
- TBF (255) : B
- a sequence of up to 254 bytes comprising the characters of the Broadcast message. The sequence may contain any control characters with the exception of NUL, which is used to terminate the string.
The following packets are used to accomplish a file transfer between nodes on the network.
The Transfer_Connect class of packets are used to establish and synchronize a connection between two nodes for the purpose of transferring a file.
The Transfer_Connect SEND packet is used to establish a connection between the local node and a node allowing remote access for the purpose of transferring a file from the remote node to the local node. The packet indicates to the remote node that it should prepare to send a file, the name of which is specified in the packet.The format of a Transfer_Connect SEND packet is as follows:
(Type = 1, Modifiers = 0) +-----+-----+ | FSZ | SPC | +-----+-----+
- FSZ (4) : B
- significant only in a response, these two words indicate the size, in 512-byte blocks, of the file to be transferred. Low-order size first, high-order second).
- SPC (100) : B
- a NUL-terminated ASCII string specifying the name of the file to be transferred.
The Transfer_Connect RECEIVE packet is used to establish a connection between the local node and a node allowing remote access for the purpose of transferring a file from the local node to the remote node. The packet indicates to the remote node that it should prepare to receive a file, the name and size of which are specified in the packet.The format of a Transfer_Connect RECEIVE packet is as follows:
(Type = 1, Modifiers = 208) +-----+-----+ | FSZ | SPC | +-----+-----+
- FSZ (4) : B
- two words indicating the size, in 512-byte blocks, of the file to be transferred. Low-order size first, high-order size second.
- SPC (100) : B
- a NUL-terminated ASCII string specifying the name of the file to be transferred.
The Transfer_Connect SEND_START packet is used only in a locally-initiated file transfer from the remote node to the local node. It signals to the remote node that the local node is prepared to receive the file. There is no specific response to this packet other than the first data block from the remote node.The format of the Transfer_Connect SEND_START packet is as follows:
(Type = 1, Modifiers = 408)
The Transfer_Data class of packets is used to transfer a 512-byte block of data between nodes participating in a file transfer.
The Transfer_Data WRITE packet is used to transfer a 512-byte block of data to be written on the receiving node.The format of the Transfer_Data WRITE packet is as follows:
(Type = 2, Modifiers = 0) +-----+----~---+ | BLK | DATA | +-----+----~---+
- BLK (4) : B
- two words indicating the block number of the transfer. Low-order first, high-order second.
- DATA (512) : B
- data buffer containing 512 bytes of data to be transferred.
The Transfer_Data READ packet is used to request a 512-byte block of data from a remote node. The response contains the requested block of data.The format of the Transfer_Data READ packet is as follows:
(Type = 2, Modifiers = 208) +-----+---~--+ | BLK | DATA | +-----+---~--+
- BLK (4) : B
- two words indicating the desired block number. Low-order first, high-order second.
- DATA (512) : B
- significant only in a response packet, contains one 512-byte block of data.
The Transfer_Disconnect class of packets is used to signal the end of a file transfer, whether the transfer completed successfully or not.
The Transfer_Disconnect END packet is used to indicate the successful completion of a file transfer.The format of a Transfer_Disconnect END packet is as follows:
(Type = 3, Modifiers = 0)A packet containing this code should only be sent by the node which is the sender in a file transfer or directory operation.
The Transfer_Disconnect ABORT packet is used to indicate that an error occurred during the file transfer.The format of the Transfer_Disconnect ABORT packet is as follows:
(Type = 3, Modifiers = 208)A packet containing this code can be sent by either node involved in a file transfer or directory operation.
The following sections define the packets used to accomplish a remote device directory.
The Directory_Connect packet is used to establish a connection between the local node and a node allowing remote access for the purposes of obtaining a directory.The format of a Directory_Connect packet is as follows:
(Type = 4, Modifiers = 00) +------+-----+ | rsvd | SPC | +------+-----+
- rsvd (4) : B
- two reserved words
- SPC (100) : B
- a NUL-terminated ASCII string specifying the device and files for which a directory is desired.
The Directory_Start packet is used to signal the remote node that it may begin sending directory data packets.The format of the Directory_Start packet is as follows:
(Code = 4, Modifiers = 208)
The Directory_Data packet is used to send a line of directory text from the remote node to the local node.The format of the Directory_Data packet is as follows:
(Type = 4, Modifiers = 408) +-------+-----+------+ | BLOCK | LEN | LINE | +-------+-----+------+
- BLOCK (4) : B
- two words containing the size in 512 byte blocks, of the file described by this packet.
- LEN (1) : B
- the count of characters in LINE (not including the trailing <200> byte)
- LINE (255) : B
- a line of directory information, terminated with a <200> byte
The Directory_End packet is used by the remote node to signal the end of the directory.The format of the Directory_End packet is as follows:
(Type = 4, Modifiers = 608)
The examples in this section illustrate the exchange of packets which occur to accomplish some operation.
The following example illustrates the exchange of RTEFTP packets required to accomplish a file transfer from Node B to Node A, requested by Node A.Table 4-1 Sample SEND Transaction, Node B to A, Node A initiator ------------------------------------------------------------------ Packet Node A Code Node B ------------------------------------------------------------------ (1) Transfer_Connect SEND [001] -> (file specification) <- [301] Transfer_Connect SEND NAK (reason) <- [101] Transfer_Connect SEND ACK (file size) Transfer_Disconnect ABORT [023] -> <- [123] Transfer_Disconnect ABORT ACK <- [123] Transfer_Disconnect ABORT ACK <- [123] Transfer_Disconnect ABORT ACK <- [123] Transfer_Disconnect ABORT ACK <- [123] Transfer_Disconnect ABORT ACK Transfer_Connect SEND_START [041] -> ------------------------------------------------------------------ (2) <- [002] Transfer_Data (block number, block) Transfer_Data ACK [102] -> Transfer_Data NAK [302] -> ------------------------------------------------------------------ (3) <- [003] Transfer_Disconnect END Transfer_Disconnect END ACK [103] -> Transfer_Disconnect END ACK [103] -> Transfer_Disconnect END ACK [103] -> Transfer_Disconnect END ACK [103] -> Transfer_Disconnect END ACK [103] -> <- [023] Transfer_Disconnect ABORT Transfer_Disconnect ABORT ACK [123] -> Transfer_Disconnect ABORT ACK [123] -> Transfer_Disconnect ABORT ACK [123] -> Transfer_Disconnect ABORT ACK [123] -> Transfer_Disconnect ABORT ACK [123] -> ------------------------------------------------------------------
- (1)
- A circuit is established between Node A (the local node) and Node B (the remote node). The file specification is passed, the file size is returned, local temporary file is created and a request is made for the remote node to begin sending the file.
- (2)
- The blocks comprising the file are sent in sequential order.
- (3)
- The transfer completes (through success or failure) and the circuit is taken down.
The following example illustrates the interchange of RTEFTP packets required to accomplish a file transfer from Node A to Node B, requested by Node A.Table 4-2 Sample RECEIVE Transaction, Node A to B, Node A initiator ------------------------------------------------------------------ Packet Node A Code Node B ------------------------------------------------------------------- (1) Transfer_Connect RECEIVE [021] -> (filespec, filesize) <- [321] Transfer_Connect RECEIVE NAK (reason) <- [121] Transfer_Connect RECEIVE ACK ------------------------------------------------------------------ (2) Transfer_Data [002] -> (block number, block) <- [302] Transfer_Data NAK <- [102] Transfer_Data ACK ------------------------------------------------------------------ (3) Transfer_Disconnect END [003] -> <- [103] Transfer_Disconnect END ACK <- [103] Transfer_Disconnect END ACK <- [103] Transfer_Disconnect END ACK <- [103] Transfer_Disconnect END ACK <- [103] Transfer_Disconnect END ACK Transfer_Disconnect ABORT [023] -> <- [123] Transfer_Disconnect ABORT ACK <- [123] Transfer_Disconnect ABORT ACK <- [123] Transfer_Disconnect ABORT ACK <- [123] Transfer_Disconnect ABORT ACK <- [123] Transfer_Disconnect ABORT ACK ------------------------------------------------------------------
- (1)
- A circuit is established between Node A (the local node) and Node B (the remote node). The file specification and size are passed, the remote temporary file is created and readiness to accept the file is signalled.
- (2)
- The blocks comprising the file are sent in sequential order
- (3)
- The transfer completes (through success or failure) and the circuit is taken down.
This chapter describes the internal operation of the RT-11 version of the program.
This portion of the program verifies that it is running under a monitor with the required support available. RTEFTP requires an RT-11 V5.5 or later XM Monitor which has been configured with timer support.
This portion of the program verifies that the required Ethernet handler is both present on the system and loaded. On CTI-based systems the NC handler is required, on Qbus-based systems the NQ handler is required and on Unibus-based systems the NU handler is required.
This portion of the program validates those operating characteristics which may be customized by the user such as the multicast address, the protocol type, the number of receive buffers and the number of virtual circuits.
The program establishes a list of additional queue elements, ensuring that they reside beyond the program as loaded, and outside PAR1 space. If this fails, there is either insufficient memory for the program to be run in the background, or insufficient pool memory for the program to be run under VBGEXE.
The program establishes a channel to the Ethernet handler, allocates a unit of the Ethernet handler and enables the multicast address and protocol type used for RTEFTP message traffic. It then establishes a second channel to provide separation of asynchronous and synchronous requests. If any part of this step fails, it could be due to the presence of other programs which access the Ethernet.The program then prepares all pre-built packets using the multicast address and protocol type.
The program determines the amount of memory available for use, then reserves space for the maximum number of access control list entries (a dynamically created and maintained linked list), the maximum number of remote node list entries and the maximum amount of dynamically-allocated memory required for all operations on all circuits.Remaining memory is allocated first for additional receive buffers for increased performance and then for additional virtual circuits for better remote accessability. For each additional virtual circuit, additional memory is reserved to ensure the availability of dynamic memory availability sufficient for all possible operations.
The data structure which defines free memory is then initialized and the reserved memory is placed on the free list for access by the memory allocation and deallocation routines.
The data structure which provides access to the access control list is initialized with an empty list.
The data structure which provides access to the remote node list is initialized with an empty list.
Each virtual circuit is initialized by marking it as available, setting its finite state machine state to Host Wait, setting its circuit number and building pointers to its internal transmit buffer.
The program cycles through all available receive buffers, posting them to the Ethernet handler.Receives which complete will be processed through the centralized receiver completion routine.
The program establishes a five-second timer for use in sending the Node_Identification message when remote access has been enabled. This timer is processed through the centralized timer completion routine.The program also establishes a one-second timer for use in timing-out entries in the remote node directory. This timer is processed through the centralized timer completion routine.
The program then enters a command loop which gathers and processes commands from the user. With the exception of request initiation, all Ethernet operations occur through completion routines.
All Ethernet operations, with the exception of the initial send or receive command or directory command, are performed in completion routines.Dispatching of timer and receiver completion routines is performed through the use of two separate routines which implement a finite state machine. One completion routine dispatches timer completions while the other dispatches receive completions.
Both routines use the same state machine tables.
All timer requests specify the same routine as the completion routine. The dispatching is done based on the timer ID.
When the one-second timer expires, this routine scans the remote node list, decrementing the timeout value for each entry. If the timeout value for an entry goes negative, the entry is removed from the list and the memory returned to the free list. If logging has been enabled, a message indicating that the node is no longer available is printed.When the list has been processed, the routine re-posts a one second timer.
When the five-second timer expires, this routine sends a Node_Identification message if a node name has has been established for this node.Whether a Node_Identification message is sent or not, the routine re-posts a five second timer before returning.
The first step in processing a receiver completion is to determine the buffer which contains the message just received. This information is contained in a byte which is an index into the table of pointers to receive buffers. When the end of the table is reached, the index is reset to zero.Once we know which buffer contains the packet, we perform further dispatching based on the contents of the packet code byte.
Once the program has identified the recieve buffer which contains the packet, the packet is validated by checking the protocol version. If it is not correct, the packet is ingored and the buffer is re-posted for receive.
Once the packet has passed the previous checks, further dispatching is performed based on the contents of the packet code byte. The table corresponding to the current state is scanned for an entry which specifies what to do with a packet of the received type. If there is no entry, the packet is ignored and the buffer is re-posted for receive. If there is an entry, the state machine for the virtual circuit transitions to the specified state and the routine to process the packet is called.
When the routine has completed, it returns to the centralized completion routine which re-posts the buffer for receive and returns.
When a Node_Identification message is received, the current remote node list is scanned to see if it has already been entered. If not, space for a new entry is allocated from free memory, the information is copied into the new list entry and it is added to the remote node list. If logging is enabled, a message is printed to report that the node is available for remote access.If the identification message is for a node for which there already seems to be an entry, the information is checked to see if it is still current. If the node name has changed and logging is enabled, a message is printed to report the name change.
If the Ethernet address for the node is different from the address stored in the entry, the packet is ignored. This is so that attempts by a node to usurp the name already in use by another node are not honored. If logging is enabled, a message is printed to report the attempt to use a name which is already in use.
When a Broadcast message is received, the local node information is referenced, specifically the bit which governs reception of broadcast messages. If the bit is reset (clear), the event is reported with a timestamp, and the message text is printed at the console terminal. If the bit is set, the message is ignored.
All error messages from RTEFTP follow the RT-11 standard for error messages, which can be demonstrated as follows:?utility-severity-text
- utility
- the name of the program, in this case RTEFTP
- severity
- a single character indication of the severity of the error, with I being informational, W being a warning, E being a recoverable error, F being a fatal error, and U being an unrecoverable error
- text
- a single line of text indicating the actual problem
The following messages are ordered first by the severity of the error (in order: I, W, E, F, U) and then alphabetized by the text of the message.
- ?RTEFTP-I-Adjacent node available - node_name
- ?RTEFTP-I-Adjacent node unavailable - node_name
- ?RTEFTP-I-Beginning directory of dev:filnam.typ for node
If the remote node is in the Remote_Node_List, its name will be reported. If it isn't, the station physical address will be reported.
- ?RTEFTP-I-Beginning receive of dev:filnam.typ from node
If the remote node is in the Remote_Node_List, its name will be reported. If it isn't, the station physical address will be reported.
- ?RTEFTP-I-Beginning send of dev:filnam.typ to node
If the remote node is in the Remote_Node_List, its name will be reported. If it isn't, the station physical address will be reported.
- ?RTEFTP-I-Directory completed, dev:filnam.typ
- ?RTEFTP-I-Node old_name changing name to new_name
- ?RTEFTP-I-Insufficient resources to queue
- ?RTEFTP-I-Node name truncated to six characters
- ?RTEFTP-I-Transfer aborted - dev:filnam.typ
- ?RTEFTP-I-Transfer completed - dev:filnam.typ
- ?RTEFTP-W-Connection timed-out to node, transfer aborted - dev:filnam.typ
- ?RTEFTP-W-Local node table is filled
- ?RTEFTP-W-Read access rejected to node node_name for dev:filnam.typ
- ?RTEFTP-W-Write access rejected to node node_name for dev:filnam.typ
- ?RTEFTP-W-Timed-out waiting for response from node node_name
- ?RTEFTP-F-Node name already in use
User Action: Check for a typing error. Verify that the specified node_name is correct and unique and retry the operation.
- ?RTEFTP-F-Ambiguous command command
User Action: Check for a typing error. Verify that the format and syntax are correct and unambiguous and retry the operation.
- ?RTEFTP-F-Ambiguous option option
User Action: Check for a typing error. Verify that the format and syntax are correct and unambiguous and retry the operation.
- ?RTEFTP-F-Ambiguous topic topic
User Action: Check for a typing error. Verify that the topic is valid and unambiguous and retry the operation.
- ?RTEFTP-F-Command too complex
User Action: Specify a command which uses fewer tokens.
- ?RTEFTP-F-Connection rejected, Access denied
- ?RTEFTP-F-Connection rejected, Device unavailable
- ?RTEFTP-F-Connection rejected, File not found
User Action: Check for a typing error. Verify that the file exists and retry the operation.
- ?RTEFTP-F-Connection rejected, Insufficient resources
User Action: Wait and retry the operation.
- ?RTEFTP-F-Connection rejected, Insufficient space available
- ?RTEFTP-F-Connection rejected, Invalid file specification
User Action: Check for a typing error. Verify that the file specification is in a proper syntax for the remote node and retry the operation.
- ?RTEFTP-F-Connection rejected, Node is not accepting connections
User Action: Wait and retry the operation.
- ?RTEFTP-F-Connection rejected, Non file-structured access
- ?RTEFTP-F-Connection rejected, Protocol mismatch
This message is obsolete.
- ?RTEFTP-F-Connection rejected, Special directory device
- ?RTEFTP-F-Connection rejected, status = nnnnnn
- ?RTEFTP-F-Connection rejected, Transfer process unavailable
This message is obsolete.
- ?RTEFTP-F-Connection rejected, Unable to close file
- ?RTEFTP-F-Connection rejected, Unable to create file
- ?RTEFTP-F-Connection rejected, Unable to perform function
- ?RTEFTP-F-Connection rejected, Unknown device
User Action: Check for a typing error. Verify that the device specified is valid for the remote node and retry the operation.
- ?RTEFTP-F-Date not set
User Action: Set the system date and time and retry the operation.
- ?RTEFTP-F-Error writing file on remote node node_name
- ?RTEFTP-F-Error writing file dev:filnam.typ
- ?RTEFTP-F-File not found dev:filnam.typ
User Action: Check for a typing error. Verify the file exists and retry the operation.
- ?RTEFTP-F-Help not available for topic
User Action: Check for a typing error. Verify that the topic is valid and retry the operation.
- ?RTEFTP-F-I/O Error
- ?RTEFTP-F-Insufficient resources
User Action: Verify that no virtual circuits are active or reduce the number of entries in the access rights list and retry the operation.
- ?RTEFTP-F-Insufficient space to expand access control list
User Action: Verify that there are no active circuits and retry the operation.
- ?RTEFTP-F-Invalid access specification
User Action: Check for a typing error. Verify that the format and syntax are correct and retry the operation.
- ?RTEFTP-F-Invalid command command
User Action: Check for a typing error. Verify that the format and syntax are correct and retry the operation.
- ?RTEFTP-F-Invalid device dev:
User Action: Check for a typing error. Verify that the device specified is valid and retry the operation.
- ?RTEFTP-F-Invalid input file dev:filnam.typ
User Action: Check for a typing error. Verify that the format and syntax are correct and retry the operation.
- ?RTEFTP-F-Invalid multiple node copy
- ?RTEFTP-F-Invalid node node_name
User Action: Check for a typing error. Verify that the format and syntax are correct and retry the operation.
- ?RTEFTP-F-Invalid option: /x
User Action: Check for a typing error. Verify that the format and syntax are correct and retry the operation.
- ?RTEFTP-F-Invalid option option
User Action: Check for a typing error. Verify that the format and syntax are correct and retry the operation.
- ?RTEFTP-F-Invalid output file dev:filnam.typ
User Action: Check for a typing error. Verify that the format and syntax are correct and retry the operation.
- ?RTEFTP-F-Invalid syntax
User Action: Check for a typing error. Verify that the format and syntax are correct and retry the operation.
- ?RTEFTP-F-Node specification required
User Action: Check for a typing error. Verify that the format and syntax are correct and retry the operation.
- ?RTEFTP-F-Only one timebase allowed
- ?RTEFTP-F-Remote access must be enabled first
User Action: Enable the local node for remote access and retry the operation.
- ?RTEFTP-F-Transfer already in progress
This message is obsolete.
- ?RTEFTP-F-Unbalanced quotes
User Action: Check for a typing error. Verify that the format and syntax are correct and retry the operation.
- ?RTEFTP-F-Unable to create file dev:filnam.typ
User Action: Free some space on the local device and retry the operation.
- ?RTEFTP-F-Unrecognized node node_name
User Action: Wait for the remote node to become available for remote access (as indicated by presence in the remote node list) and retry the operation.
- ?RTEFTP-U-Error opening channel to Ethernet
User Action: Remove the Ethernet handler (NC, NQ or NU), reinstall it and attempt the operation again.
- ?RTEFTP-U-Ethernet handler must be loaded - dev
User Action: Load the appropriate handler by using the LOAD command and retry the operation.
- ?RTEFTP-U-Ethernet handler not available - dev
User Action: Make sure the appropriate Ethernet handler (NC, NQ or NU) is available on the system. Ensure that it is installed and retry the operation.
- ?RTEFTP-U-Insufficient memory
User Action: Free some background space by unloading unused handlers and programs or try running RTEFTP under VBGEXE. (Refer to section 3 of the RT-11 System Message Manual.)
- ?RTEFTP-U-Insufficient pool memory, use /BUFF:xxx
User Action: Retry the operation specifying a larger pool using the '/BUFF:xxx' qualifier as reported.
- ?RTEFTP-U-Invalid multicast address
User Action: Correct the previously applied customization.
- ?RTEFTP-U-Invalid protocol type
User Action: Correct the previously applied customization.
- ?RTEFTP-U-Multicast enable error
User Action: Remove any currently active programs which use the Ethernet and retry the operation.
- ?RTEFTP-U-Protocol enable error
User Action: Remove any currently active programs which use the Ethernet and retry the operation.
- ?RTEFTP-U-Timer support required
User Action: RTEFTP requires timer support. Perform a system generation and select timer support. Boot the resulting XM Monitor and retry the operation.
- ?RTEFTP-U-Unit allocation error
User Action: Remove any currently active programs which use the Ethernet and retry the operation.
- ?RTEFTP-U-Unable to reopen asynchronous I/O channel
- ?RTEFTP-U-Unable to reopen synchronous I/O channel
- ?RTEFTP-U-Unable to save channel status
- ?RTEFTP-U-Wrong version of RT-11
User Action: Boot a V5.5 or later XM Monitor (with timer support) and retry the operation.
- ?RTEFTP-U-XM Monitor required
User Action: RTEFTP requires an XM Monitor. Perform a system generation, select XM (with timer support). Boot the resulting XM Monitor and retry the operation.
Appendix B
RTEFTP Packet CodesB.1 Packet Codes
Packet codes are found in the first byte of any RTEFTP packet and are used to indicate the contents of the packet beyond the packet header.In the following lists, all numbers are in unsigned octal.
B.1.1 Packet Types
The packet type, bits <03:00> of the packet code byte, are used to encode the type of packet.Table B-1 Packet Types -------------------------------------------------- Code Meaning -------------------------------------------------- 0 Control 1 Transfer_Connect 2 Transfer_Data 3 Transfer_Disconnect 4 Directory 5-17 undefined and reserved --------------------------------------------------B.1.2 Packet Type Modifiers
The packet type modifiers, bits <05:04> of the packet code byte, are used to further define the contents of the packet.Table B-2 Control Packet Modifiers -------------------------------------------------- Code Meaning -------------------------------------------------- 0 Node_Identification packet 20 Broadcast packet 40 undefined and reserved -------------------------------------------------- Table B-3 Transfer_Connect packet modifiers -------------------------------------------------- Code Meaning -------------------------------------------------- 0 SEND 20 RECEIVE 40 SEND_START 60 undefined and reserved -------------------------------------------------- Table B-4 Transfer_Data packet modifiers -------------------------------------------------- Code Meaning -------------------------------------------------- 0 WRITE 20 READ 40 undefined and reserved 60 undefined and reserved -------------------------------------------------- Table B-5 Transfer_Disconnect packet modifiers -------------------------------------------------- Code Meaning -------------------------------------------------- 0 END 20 ABORT 40 undefined and reserved 60 undefined and reserved -------------------------------------------------- Table B-6 Directory packet modifiers -------------------------------------------------- Code Meaning -------------------------------------------------- 0 Connect 20 Start 40 Data 60 End --------------------------------------------------The high order two bits of the packet code byte, bits <07:06>, are used to indicate the kind of packet.
Table B-7 Packet modifiers -------------------------------------------------- Code Meaning 0 Message 100 ACK response 200 undefined and reserved 300 NAK response --------------------------------------------------Combinations of the above-defined codes are ORed together, forming packet codes from the following list:
Table B-8 Packet codes -------------------------------------------------- Code Meaning -------------------------------------------------- 0 Node_Identification 1 Transfer_Connect SEND 2 Transfer_Data WRITE 3 Transfer_Disconnect END 4 Directory Connect 20 Broadcast 21 Transfer_Connect RECEIVE 22 Transfer_Data READ 23 Transfer_Disconnect ABORT 24 Directory Start 41 Transfer_Connect SEND_START 44 Directory Data 64 Directory End 101 Ack, Transfer_Connect SEND 102 Ack, Transfer_Data WRITE 103 Ack, Transfer_Disconnect END 104 Ack, Directory Connect 121 Ack, Transfer_Connect RECEIVE 122 Ack, Transfer_Data READ 123 Ack, Transfer_Disconnect ABORT 144 Ack, Directory Data 164 Ack, Directory End 301 Nak, Transfer_Connect SEND 302 Nak, Transfer_Data WRITE 303 Nak, Transfer_Disconnect END 304 Nak, Directory Connect 321 Nak, Transfer_Connect RECEIVE 322 Nak, Transfer_Data READ 323 Nak, Transfer_Disconnect ABORT 344 Nak, Directory Data --------------------------------------------------
Appendix C
RTEFTP Status CodesThe following table lists the status codes which may be returned in the second byte of an RTEFTP NAK packet.In the following table, all numbers are in unsigned octal.
Table C-1 Status Codes -------------------------------------------------- Code Meaning -------------------------------------------------- 377 Transfer process unavailable (obsolete) 376 Invalid file specification 375 Unknown device 374 Device unavailable 373 File not found 372 Unable to create file 371 Unable to close file 370 Protocol mismatch (obsolete) 367 Insufficient space available 366 Non-file-structured access 365 Access denied 364 Special directory device 363 Insufficient resources 362 I/O error 361 Unable to perform function 360 Node is not accepting connections --------------------------------------------------In designing the file transfer protocol, care was taken to try to make the error codes as system-independent as possible. This list may expand as versions of RTEFTP appear for other operating systems.
Appendix D
File System CodesThe file system codes are defined in the bootblock standard and are included here for reference purposes.7 6 5 4 3 2 1 0 +-----+-----+-----+-----+-----+-----+-----+-----+ | CUS | TYPE | LEVEL | +-----+-----+-----+-----+-----+-----+-----+-----+ CUS indicates customer/CSS file system TYPE indicates file system type LEVEL indicates file system levelIn the following table, all numbers are in unsigned octal.
Table D-1 File System Codes -------------------------------------------------- Code Meaning -------------------------------------------------- 0 Unknown 10 PDP-8 20 RT-11 30 RSTS 40 Files-11 (ODS-1 or ODS-2) 50 U**x 60 DSM 70 unknown 100 CP/M 110 UCSD P-system 120 MS-DOS 130-170 undefined and reserved 200-370 Customer/CSS use --------------------------------------------------
Appendix E
Customization patchesE.1 Customization patches for RTEFTP
This section describes customization patches which may be applied to RTEFTP to change certain operational characteristics.E.1.1 Automatic VBGEXE
This customization patch causes RTEFTP to run under VBGEXE context whenever it is run.This patch applies to V5.6 and is not yet implemented.
E.1.2 Changing Number of Receive Buffers
This customization patch alters the number of receive buffers for which RTEFTP will attempt to reserve space. More receive buffers increases performance by decreasing the chance that there will not be a receive buffer available when a packet is received..sipp rteftp.sav/a Base? 0 Offset? ..RCV Base Offset Old New? 000000 ..RCV 000006 \ Base Offset Old New? 000000 ..RCV 006000000 ..RCV+1 000 ^Y Regardless of the number selected through patching, the program will ensure that there are no fewer than two and no more than six receive buffers. This will be enforced at run-time.
For performance reasons, the space for additional receive buffers is allocated first, so this will have an affect on the number of virtual circuits which may be available.
E.1.3 Changing Number of Virtual Circuits
This customization patch alters the number of virtual circuits for which RTEFTP will attempt to reserve space. More virtual circuits makes the system available for more simultaneous accesses..sipp rteftp.sav/a Base? 0 Offset? ..CIR Base Offset Old New? 000000 ..CIR 000010 \ Base Offset Old New? 000000 ..CIR 010000000 ..CIR+1 000 ^Y E.1.4 Changing Multicast Address
This customization patch alters the multicast address used by RTEFTP for control packets. It should not be altered unless it is determined that operation of RTEFTP is conflicting with another program using the same multicast address.E.1.5 Changing Protocol Type
This customization patch alters the protocol type used by RTEFTP for all packets. It should not be altered unless it has been determined that operation of RTEFTP is conflicting with another program using the same protocol type.