Programmer's ROM - The Computer Language Library

home *** CD-ROM | disk | FTP | other *** search

/ Programmer's ROM - The Computer Language Library / programmersrom.iso / ada / defdata / usersman.doc < prev next >

Wrap

Text File | 1988-05-03 | 102.7 KB | 2,554 lines

--:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: --tcp.man --:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 1. TCP 1.1 Functional Description The Transmission Control Protocol(TCP) resides in the transport layer of the DOD Internet Model. It encapsulates messages received from the Utility layer protocols which reside directly above and passes the packet to the Internet layer (communicates with the Internet Protocol(IP)). TCP provides a reliable communication between pairs of processes in logically distinct hosts on networks and sets of interconnected networks. The following is a list of functions that are supported by the protocol: a. Connection-oriented b. Reliable data transfer c. Ordered data transfer delivery d. Full-duplex e. Flow control TCP communicates with both upper and lower layer protocols by means of response and request primitives. A multiplexing mechanism is built into TCP to support multiple Upper Layer Protocol (ULP) processes by a single TCP process. Messages passed into TCP from ULPs are buffered and sent when the appropriate size is adequate for efficient transfer or internal processing warrants communication. All communication between entities is synchronized and flow control mantained by TCP. The basic data transfer provides the capability to transfer a continuous bit stream from one user to another. It provides an urgent service, which provides an indication to the user that some portion of the data transfer is more important than usual. It provides a push function which assures that any data currently stored by the intermediate switch will be sent immediately. The reliability facility assures that if the information is received by the receiving user, it will be received correctly and in the same order as it was sent. Multiplexing provides for multiple users to share communications facilities. It allows many processes within single host to share TCP communication facilities by providing each process a different port. A unique address, called a socket, is formed from the concatenation of the port address with the network and host address from the internet communication layer. Connection management provides for establishing connections assigning a unique name for each connection, and initializing status information for reliability and flow control. Handshaking is used to unambiguously and reliably establish each connection. The state of each connection is maintained to assure correct operation. An orderly procedure to close a connection has also been established. The TCP layer assumes only that it has a (perhaps unreliable) datagram service available for transmission. This datagram service is provided by the Internet Protocol. The implementation of TCP perform efficient segmentation of data and reassembly of segments. If a segment arrives in the window but out of order it will be retained until the preceding segments arrive, at which time the segments may be passed on to the layer of protocol above TCP. This philosophy will prevent needless retransmissions. Buffers sent to TCP from both upper and lower level protocols are not necessarily delivered immediately. TCP segmentizes messages only in the event of a push flag will buffers be forwarded to the local ULP or IP. This version of the TCP conforms to RFC:793, the Transmission Control Protocol Darpa Internet Program Protocol Specification from September 1981. It is designed so that it is effectively decoupled from the layers above and below it. 1.2 Using TCP TCP communicates with upper and lower protocols via queues, request primitives, and response primitives. The queues that interface the ULPs to TCP are structure with one queue for all request to TCP. Each connection a ULP has, TCP will communicate all response to a queue unique for that connection. Request Primitives are sent by corresponding ULP(s) to generate specific action by TCP. The sending of a request primitive does not warrant an immediate response or action by TCP. The following is a list of requests supported by TCP: a. Passive Unspecified Open : TCP will accept an open request from any other TCP. b. Passive Specified Open : TCP will accept an open request only from the specified socket. c. Active Open : TCP initiates an open to establish a connection. d. Status : The ULP request TCP status information concerning the specified connection. e. Allocate : The ULP request that TCP allocate a receive buffer. f. Close: The ULP request that TCP begin closing sequence with remote ULP. g. Send Data : ULP sends data to be sent to remote ULP, Urgent flag and Push data are also included in request. h. Abort : Terminate connection. Response Primitives are sent by TCP to a specified ULP queue. The following is a list of responses supported by TCP: a. Buffer for User : contains data for user b. Pushed Buffer for User : data has been pushed by remote TCP c. Connection Illegal : user attempts to open a connection that is not legal. d. Connection does not exist : user attempt an operation on a connection that has not been opened. e. Return Local Connection Name : local connection name is returned after a ULP attempts an open request primitive. f. Insufficient Resources : returned when a request primitive exceeds TCP present resource allocation for the connection. g. Connection Closing : a remote ULP has requested to close the connection; the local ULP should finish all processing and send a close request primitive. h. Urgent Data : urgent data is forthcoming. i. OK on Abort : confirms a successful abort. j. Precedence not allowed: ULP precedence mismatch. k. Connection Exists : An request primitive was issued for an already established connection. l. TCB pointer and state : reply from TCP with respect to a status request primitive. m. Connection Reset : confirms a successful reset. n. OK on close : confirms a successful reset o. Connection now open : confirms the successful establishment of a connection. p. IP overloaded : IP resources exhausted. q. Could not do reset : TCP cannot reset connection. r. Out of Buffers : system buffer resource exhausted. s. Pushed Buffer for user : confirms send data request primitive for a pushed buffer. t. Connection Refused : TCP cannot make connection. 1.3 Sample Session ULP - TCP Communication Upon initialization TCP's ports are closed. A ULP must send an unspecified or specified request to set the connection state to listen. An active OPEN can also be requested with the connection state either closed or listening. An example of a connection opening, sending data, and closing is shown below: --procedure calls from package specification WITH_USER_ COMMUNICATE --ULP wants to setup Telnet connection in listen state(unspecified) OPEN_PARAMETERS : OPEN_PARAMS; TCP_MESSAGE : MESSAGE; OPEN_PARAMETERS := (LOCAL_PORT, --Telnet Port (23) -1, --unspecified foreign port -1, --unspecified foreign net host PASSIVE, --passive open BUFFER_SIZE TIME_OUT LOCAL_CONNECTION_NAME, SECURITY, PRECEDENCE, OPTIONS); TCP_MESSAGE := (OPEN, OPEN_PARAMETERS); MESSAGE_FOR_TCP(TCP_MESSAGE); --read user queue for Local Connection Name USER_MESS : USER_MESSAGE; WAIT_FOR_TCP_MESSAGE( USER_MESS); -- USER_MESS.MESSAGE_NUMBER = 14 --Return LCN --this LCN is the port's LOCAL_CONNECTION_NAME LOCAL_CONNECTION_NAME:=USER_MESS.LOCAL_CONNECTION_NAME; --User decides to open a connection OPEN_PARAMETERS:=(LOCAL_PORT, --Telnet Port(23) FOREIGN_PORT, FOREIGN_NET_HOST, ACTIVE, --active open BUFFER_SIZE TIME_OUT LOCAL_CONNECTION_NAME, SECURITY, PRECEDENCE, OPTIONS); TCP MESSAGE := ( OPEN, OPEN PARAMETERS); MESSAGE_FOR_TCP(TCP_MESSAGE); --read user queue for Local Connection Name USER_MESS : USER_MESSAGE; WAIT_FOR_TCP_MESSAGE( USER_MESS); -- USER MESS.MESSAGE_NUMBER = 14 --Return LCN -- this LCN is the port's LOCAL_CONNECTION_NAME --Since a passive open was already attempted this assignment is not --necessary(only if the state was closed) LOCAL_CONNECTION_NAME :=USER_MESS.LOCAL_CONNECTION_NAME; --allocated receive buffer BUFFER : PACKED BUFFER_PTR; RECEIVE_DATA : RECEIVE_PARAMS; BUFFGET( BUFFER, 1); --obtain buffer BUFFER.TELNET_PTR :=MAX_DATAGRAM_SIZE; --constant in package BUFFER_DATA --specification RECEIVE_DATA:=(LOCAL_CONNECTION_NAME, BUFFER, RECEIVE_BUFFER_ SIZE); TCP_MESSAGE := (RECEIVE, RECEIVE_DATA); MESSAGE_FOR_TCP(TCP_MESSAGE); --user sends data SEND_PARAMETERS : SEND_PARAMS; BUFFGET( BUFFER, 1); --obtain buffer --data must be converted to system.byte BUFFER.TELNET_PTR :=MAXIMUM_DATAGRAM_SIZE; SEND_PARAMETERS: = (LOCAL_CONNECTION_NAME, BUFFER, --buffer with data MESSAGE_SIZE PUSH_FLAG URG_FLAG, TIME_OUT); TCP_MESSAGE := (SEND, SEND_PARAMETERS), MESSAGE_FOR_TCP( TCP_MESSAGE); --user receives a message from remote ULP WAIT_FOR_TCP_MESSAGE(USER_MESS); --USER_MESS.MESSAGE_NUMBER = 10 --buffer for user --convert message from SYSTEM.BYTE --user closes connection CLOSE_PARAMETERS : ABORT_CLOSE_PARAMS; CLOSE_PARAMETERS.LCN :=LOCAL_CONNECTION_NAME; TCP_MESSAGE := (CLOSE, CLOSE_PARAMETERS); MESSAGE_FOR_TCP( TCP_MESSAGE); --wait for "OK on Close" WAIT_FOR_TCP_MESSAGE( USER_MESS); --USER_MESS.MESSAGE_NUMBER_NUMBE = 18 ==OK on Close --connection is now in close state The security clearance of each participant in the network is maintained to avoid compromise of data during an exchange. This version of TCP checks security parameters however, since a security policy has not been established it is left for future implementations to insert code to deny or grant access privileges. The implementation does check security and precedence levels before a connection is established to make sure that both entities match. In the event of a mismatch the connection is reset. Flow control is used to assure that the receiver has sufficient resources to correctly receive the data transmitted. This prevents needless data transmissions and network congestion. It is accomplished using a sliding window techinique with dynamic window management. 1.4 TCP Computer Program Overview 1.4.1 Hardware - This implementation of TCP is targeted for a VAX 11/780 and Wicat workstation. 1.4.2 Operating System - This implementation of TCP is targeted for VMS 4.0 and ROS. 1.4.3 Ada Compiler Implementation - This implementationi of TCP is written in Telesoft-Ada version 1.3d for the WICAT. The VAX 11/780 implementation uses the DEC/Ada compiler. 1.4.4 Package Overview - TCP is structured to run independently of other protocols and communication is realized via queues. The queue structure is shown in figure 1. Operations on the queues are system dependent. Therefore, only the specification of the TCP communication package is portable. TCP is event driven with input from the TOTCPQUEUE. This queue receives input from both the ULP and IP. Rationale for one queue was for efficiency considerations. TCP has been designed and implemented in such a way that it can be run as a detached process or via a procedure call from some program. A controller is called to execute TCP. This procedure reads an input queue from which both upper and lower layer protocols input. Appropriate routines are invoked with respect to input primitives. The packages were grouped into five categories: 1. Communication 2. Utilities 3. Transmission Control Block Management 4. TCP controller 5. Segment Arrives The communication packages are system dependent and vary between system implementations. TCP for VMS uses mailboxes to communicate between its ULPs, while the WICAT/ROS version utilities share data structures (queues). This was due to TCP and ULPs running was detached processes on VMS. The utilities package clock and date function are system dependent and are designed to interface with specifics of the operating systems. The remaining utilities, transmission control block management, TCP controller, and segment arrives packages are system independent. Portability is maintained across any system running Telesoft Ada version 1.5 or 1.3. WICAT -----------------------------------COMMUNICATION------------------------------- WITH_TCP_COMMUNICATE WITH_IP_COMMUNICATE WITH_USER_COMMUNICATE -----------------------------------UTILITIES----------------------------------- REAL_TIME_CLOCK_DATE MODULO TCP_GLOBALS BUFFER_DATA -------------------TRANSMISSION CONTROL BLOCK MANAGEMENT----------------------- TCP_ALLOCATOR T_TCP_GLOBALS_DATA_STRUCTURES QUEUES ------------------TCP_CONTROLLER---------------------------------- TCP_CONTROL_AND_USER_FUNCTIONS TCP_CONTROLLER_UTILITIES -------------------------------SEGMENT ARRIVES--------------------------------- TCP_SEGMENT_ARRIVES_PROCESSING TCP_ARRIVES_PERIPHERALS ------------------------------------------------------------------------------- A description of the packages for TCP are described below: 1.4.4.1 Communication Interface - a. WITHUSERCOMMUNICATE : ULP(s) use this to write and read from TCP queues. The body of these functions and procedures are system dependent. Data structures provided for communication are common with WITHTCPCOMMUNICATE package. This enables TCP and ULP(s) to coexist on a system as separate processes. b. WITHTCPCOMMUNICATE : Contains data structures and operations to enable TCP to communicate with queues of upper and lower level protocols. The body of this package is system dependent and not portable. c. BUFFERDATA : Messages travel through the DoD Internet Model by each Protocol layer encapsulating the message with a header. The realization of this mechanism uses an array of SYSTEM.BYTE with pointers to indicate where each header resides (figure 2). Upon receiving a message the protocol uses a pointer to gain access to the beginning of its header. The package is implementation dependent. Its intent is to facilitate the portability of this communications program by narrowing the packages to be changed to an absolute minimum for different machines. d. WITHIPCOMMUNICATE : Enables TCP to communicate with IP queues. e. QIO : This package is used only TCP implementations running on VMS. Telesoft Ada 1.5 hooks were made into the operation system to access system services for mailboxes and QIO. f. SUBNETCALLS : This package contains procedure calls and data structures necessary for the Internet Protocol Group and the Subnet Protocol Group to communicate. A counter is maintained which indicates how many elements each queue contains (of queue elements in use). All procedures contain an error parameter which is returned for the appropriate condition generated. 1.4.4.2 TCP Controller - a. TCPCONTROLANDUSERFUNCTIONS : The procedure TCPCONTROLLER is called to control and operate the TCP layer. It determines the necessary actions after it gets a message from the communication queues. b. TCPCONTROLLERUTILITIES : The following procedures perform processing for each specific event : 1. TCPSEND : This procedure will process a send request from the user. 2. TCPABORT : This procedure will cause a connection to be aborted. The user requests this action. 3. TCPRECEIVE : This procedure will cause any data from a remote site to the user to be returned to the user. 4. TCPCLOSE : This procedure will cause a connection to be closed. 5. TCPOPEN : This procedure will attempt to open an active or passive connection to a remote host as required by the user. 6. TCPSTATUS : This procedure will retransmit the first packet in thye retransmit queue. 1.4.4.3 Utilities For TCP - a. REALTIMECLOCKDATA : Provides the user with the system local time and date. b. TCPGLOBALS : This package provides operations for TCP to pack segments, format the header, checksum, address decoding and verification, and timing functions. c. MODULO : Provides implementation with the ability to handle 32 bit numbers. 1.4.4.4 Transmission Control Block Management - a. TCBALLOCATOR : This package provides five Transmission Control Block (TCB) operations. Upon package initialization, TCBs are generated and placed on a free list; procedure to remove a TCB from a free list and place it on an in-use list; procedure to clear a TCB; procedure to remove a TCB from the in-use list and place it on the free-list; obtain the head of the in-use list. b. TTCPGLOBALSDATASTRUCTURES : Defines the data structures that are used throughout TCP(TCB and queues). c. QUEUES : Provides operations for TCP queue management. TCP contains five queues : TRANSMITQUEUE; TCPRETRANSMITQUEUE; TCPRECEIVEDSEGMENTQUEUE; RECEIVEQUEUE; PROCESSEDSEGMENTSFORUSERQUEUE. 1.4.4.5 Segment Arrives - a. TCPSEGMENTARRIVESPROCESSING : Determines from a segment what the LCN is. It then determines if the segment is valid in terms of sequence number and checksum. The segment is then processed with respect to connection state. b. TCPARRIVESPERIPHERALS : Provides procedures and functions necessary for processing arrived segments (as process from TCPSEGMENTARRIVESPROCESSING). 1.5 Portability Issues TCP has been implemented to run on any system supporting Telesoft Ada version 1.3 or 1.5 with the exception of the communication packages. These packages are dependent on the operating system service calls that are essential for TCP communication between layers. This stems from TCP's multiplexing characteristics and its implementation on multiuser systems. 1.6 Installation Issues For the VAX/VMS implementation of TCP it was necessary to modify Telesoft Ada Run Time Kernal(RTK) for support of mailboxes and QIO system services. The modifications are contained in the VMS command file label QIO.COM. Execution of this file with the marco program QIO.MAR, performs all modifications necessary for the RTK. No modifications were made on the RTK of the LABTEK WICAT Telsoft system. 1.7 MIL - STD 1777 Vs RFC 793 vax 11/780 --------------------------------COMMUNICATION---------------------------------- WITH_TCP_COMMUNICATE TCP_TO_ULP_COMMUNICATE GET_MESSAGE_FROM_ULP SEND_IP_TASK TCP_Q_TASK IP_TCP SUBNET_CALLS ---------------------------------UTILITIES------------------------------------- REAL_TIME_CLOCK_DATE MODULO TCP_GLOBALS BUFFER_DATA ---------------------TRANSMISSION CONTROL BLOCK MANAGEMENT--------------------- TCP_ALLOCATOR T_TCP_GLOBALS_DATA_STRUCTURES QUEUES ---------------TCP_CONTROLLER------------------------------- TCP_CONTROL_AND_USER_FUNCTIONS TCP_CONTROLLER_UTILITIES ---------------------------------SEGMENT ARRIVES------------------------------- TCP_SEGMENT_ARRIVES_PROCESSING TCP_ARRIVES_PERIPHERALS ------------------------------------------------------------------------------- A description of the packages for TCP are described below: 1.7.0.1 Communication Interface - a. GETMESSAGEFROMULP and TCPTOULPCOMMUNICATE : Provides necessary functions for TCP to communicate with the ULP's. The body of these functions and procedures are system dependent. Data structures provided for communication are common with WITHTCPCOMMUNICATE package. This enables TCP and ULP(s) to coexist on a system as separate processes. b. WITHTCPCOMMUNICATE : Contains data structures and operations to enable TCP to communicate with queues of upper and lower level protocols. The body of this package is system dependent and not portable. c. BUFFERDATA : Messages travel through the DoD Internet Model by each Protocol layer encapsulating the message with a header. The realization of this mechanism uses an array of SYSTEM.BYTE with pointers to indicate where each header resides (figure 2). Upon receiving a message the protocol uses a pointer to gain access to the beginning of its header. The package is implementation dependent. Its intent is to facilitate the portability of this communications program by narrowing the packages to be changed to an absolute minimum for different machines. d. SUBNETCALLS and SENDIPTASK : Enables TCP to communicate to and from IP queues. e. IPTCP and TCPQTASK : Provides functions necessary to operate upon queues TCP uses to hold datagrams and messages. 1.7.0.2 TCP Controller - a. TCPCONTROLANDUSERFUNCTIONS : The procedure TCPCONTROLLER is called to control and operate the TCP layer. It determines the necessary actions after it gets a message from the communication queues. b. TCPCONTROLLERUTILITIES : The following procedures perform processing for each specific event: 1. TCPSEND : This procedure will process a send request from the user. 2. TCPABORT : This procedure will cause a connection to be aborted. The user requests this action. 3. TCPRECEIVE : This procedure will cause any data from a remote site to the user to be returned to the user. 4. TCPCLOSE : This procedure will cause a connection to be closed. 5. TCPOPEN : This procedure will attempt to open an active or passive connection to a remote host as required by the user. 6. TCPSTATUS : This procedure will retransmit the first packet in the retransmit queue. 1.7.0.3 Utilities For TCP - a. REALTIMECLOCKDATA : Provides the user with the system local time and date. b. TCPGLOBALS : This package provides operations for TCP to pack segments, format the header, checksum, address decoding and verification, and timing functions. c. MODULO : Provides implementation with the ability to handle 32 bit numbers. 1.7.0.4 Transmission Control Block Management - a. TCBALLOCATOR : This package provides five Transmission Control Block (TCB) operations. Upon package initialization, TCBs are generated and placed on a free list; procedure to remove a TCB from a free list and place it on an in-use list; procedure to clear a TCB; procedure to remove a TCB from the in-use list and place it on the free-list; obtain the head of the in-use list. b. TTCPGLOBALSDATASTRUCTURES : Defines the data structures that are used throughout TCP(TCB and queues). c. QUEUES : Provides operations for TCP queue management. TCP contains five queues : TRANSMITQUEUE; TCPRETRANSMITQUEUE; TCPRECEIVEDSEGMENTQUEUE; RECEIVEQUEUE; PROCESSEDSEGMENTSFORUSERQUEUE. 1.7.0.5 Segment Arrives - a. TCPSEGMENTARRIVESPROCESSING : Determines from a segment what the LCN is. It then determines if the segment is valid in terms of sequence number and checksum. The segment is then processed with respect to connection state. b. TCPARRIVESPERIPHERALS : Provides procedures and functions necessary for processing arrived segments (as process from TCPSEGMENTARRIVESPROCESSING). 1.8 Portability Issues TCP has been implemented to run on any system supporting Telesoft Ada version 1.3 or 1.5 and the DEC Ada compiler. These packages are dependent on the operating system service calls that are essential for TCP communication between layers for the DEC Ada implementation. This stems from TCP's multiplexing characteristics and its implementation on multiuser systems. 1.9 Installation Issues For the VAX/VMS implementation of TCP, it was necessary to use mailboxes for communication since the ULP's would be executed as separate VMS processes. The Wicat implementation executed as a single bound program. 1.10 Diagram Of The TRANSMISSION CONTROL PROTOCOL Hierarchy. TCP_CONTROLLER +----------------+-----------+----+---+-----+----------+-----------+ TCP_ERROR RETRANS_TCP TCP_STATUS TCP_SEND TCP_RECEIVE TCP_ABORT +------------+-----------+ QUEUE_ADD QUEUE_GET send_ip +-------------------+--------------+ TCP_CLOSE TCP_OPEN TCP_SEG_ARRIVE +---+----------+-------------+ SEND_A_SYN message_for_user START_TIMER message_for_user TCP_RECEIVE +-------------+------------+------------+----------------+ MESSAGE_FROM_USER QUEUE_GET QUEUE_ADD BUFFREE INSERT_TEXT_IN _BUFFER TCP_CLOSE -------------------+------------------------- QUEUE_EMPTY TCB_CLEAR QUEUE_CLEAR SEND_A_FIN message_for_user message_for_user TCP_ABORT +--------------+-----------+ TCP_ERROR QUEUE_CLEAR TCB_CLEAR TCP_SEND +----------------------+---+-+----+------------+--------------+ PACK_BUFFER_INTO_BIT_STREAM send_ip BUFFGET TCP_HEADER_FORMAT QUEUE_ADD +--------------------------+----------------------+ MESSAGE_FROM_USER SEND_FROM_TRANSMIT_QUEUE BUFFREE TCP_SEG_ARRIVE +---------------------------+--------+---------------------------+ SEQUENCE_NUMBER_CHECKER START_TIMER SEG_ARRIVED_IN_CLOSED_STATE +-------------------------+------------------------+---------+ SEG_ARRIVED_IN_LISTEN_STATE SEG_ARRIVED_IN_SYN_RECEIVED_STATE BUFFREE +-------------------------+-------------------------+ SEG_ARRIVED_IN_ESTABLISHED_STATE SEG_ARRIVED_IN_FIN_WAIT_1_STATE +---------------------------+-------------------------+ SEG_ARRIVED_IN_FIN_WAIT_2_STATE SEG_ARRIVED_IN_SYN_SENT_STATE _+-------------------------+----------- SEG_ARRIVED_IN_CLOSE_WAIT_STATE SEG_ARRIVED_IN_CLOSING_STATE +-----------------------------+------------------------+ SEG_ARRIVED_IN_LAST_ACK_STATE UNPACK SEG_ARRIVED_IN_TIME_WAIT_STATE SEG_ARRIVED_IN_CLOSED_STATE +-------------------+-------------------+ SEND_A_RESET SEND_A_RESET_AND_ACK BUFFREE SEG_ARRIVED_IN_LISTEN_STATE +-----------+------+------------------+--------------+----------------+ QUEUE_ADD TCB_CLEAR SEND_A_RESET BUFFREE SEND_A_SYN_AND_ACK CHECK_OPTIONS SEG_ARRIVED_IN_SYN_RECEIVED_STATE +-------+-------+--------------+---------------+ SEND_A_RESET BUFFREE BAD_SYN_HANDLER ENTER_ESTABLISHED_STATE_PROCESSING +------------------+------------------+ QUEUE_ADD BUFFREE MESSAGE_FOR_USER SEG_ARRIVED_IN_ESTABLISHED_STATE +-----------------+---------------+------------+---------------+ TCB_CLEAR TCP_ERROR QUEUE_CLEAR BAD_SYN_HANDLER +-------------------------+-----+---------------------+ MESSAGE_FOR_USER BUFFREE PROCESS_URGENT_FLAG +---------------------------+---------------+ PROCESS_COMMON_ACK SEND_A_PIGGYBACKED_ACK +-----------------------+-----------------+ PROCESS_RESET_IN_DATA_ACCEPTING_STATES FIN_CHECK_FOR_ESTABLISHED_OR_SYN_RECEIVED_STATES SEG_ARRIVED_IN_FIN_WAIT_1 +-------------------------+-----------+------------+--------------+ BAD_SYN_HANDLER PROCESS_URGENT_FLAG PROCESS_COMMON_ACK BUFFREE +---------------------------+-+-------------+-----------+ PROCESS_RESET_IN_DATA_ACCEPTING_STATES PROCESS_SEGMENT_TEXT QUEUE_EMPTY PROCESS_A_FIN SEG_ARRIVED_IN_FIN_WAIT_2 +------------------+-------------+-------------+----------------+ BAD_SYN_HANDLER PROCESS_A_FIN PROCESS_COMMON_ACK PROCESS_URGENT_FLAG +------------------------------+-------------+-----------+---------+ PROCESS_RESET_IN_DATA_ACCEPTING_STTES PROCESS_SEGMENT_TEXT BUFFREE QUEUE_EMPTY SEG_ARRIVED_IN_SYN_SENT_STATE +------------------+------------+--------+------------+ SEND_A_RESET SEND_A_PIGGYBACKED_ACK SEND_A_RESET_AND_ACK BUFFREE +-------------------+------------+-----------+--------------------+ CHECK_OPTIONS QUEUE_ADD DELETE_FROM_RETRANS_QUEUE QUEUE_CLEAR +---------------------+----------------------+ MESSAGE_FOR_USER COPY_NEC_TCB_FIELDS SEG_ARRIVED_IN_CLOSE_WAIT_STATE +-----------------+---------------+-------------+ BAD_SYN_HANDLER PROCESS_COMMON_ACK BUFFREE PROCESS_RESET_IN_DATA_ACCEPTING_STATES SEG_ARRIVED_IN_CLOSING_STATE +--------+----------+--------+---+--------------+ START_TIMER BAD_SYN_HANDLER BUFFREE PROCESS_COMMON_ACK +--------------+------------+ QUEUE_EMPTY QUEUE_CLEAR TCB_CLEAR SEG_ARRIVED_IN_LAST_ACK_STATE +----------------+--------------+----+--------+-------+ DELETE_FROM_RETRANS_QUEUE BAND_SYN_HANDLER TCB_CLEAR BUFFREE +------------------+--------------+-------------+ MESSAGE_FOR_USER TCB_CLEAR QUEUE_CLEAR SEG_ARRIVED_IN_TIME_WAIT_STATE +---------------+------------+-----+-----------------+ TCB_CLEAR BAD_SYN_HANDLER BUFFREE SEND_A_PIGGYBACKED_ACK +------------------+-------------------+ QUEUE_CLEAR START_TIMER SEND_A_RESET +-------------+-------+---------+---------------+ MESSAGE_FOR_USER TCP_HEADER_FORMAT send_ip PACK_BUFFER_INTO_BIT_STREAM SEND_A_RESET_AND_ACK +---------+---------+-------------+ TCP_HEADER_FORMAT send_ip PACK_BUFFER_INTO_BIT_STREAM SEND_A_SYN_AND_ACK +---------------+---------+--+-----+-------------+ MESSAGE_FOR_USER TCP_HEADER_FORMAT send_ip PACK_BUFFER_INTO_BIT_STREAM QUEUE_ADD BAD_SYN_HANDLER +------------------+-------------+----------------------+ BAD_SYN_HANDLER QUEUE_CLEAR MESSAGE_FROM_USER ENTER_ESTABLISHED_STATE_PROCESSING +----------------+---------------+--------------+ PROCESS_URGENT_FLAG PROCESS_SEGMENT_TEXT QUEUE_GET FIN_CHECK_FOR_ESTABLISHED_OR_SYN_RECEIVED_STATES PROCESS_URGENT_FLAG message_for_user PROCESS_SEGMENT_TEXT +----------+-----------+-----------------------------------+ QUEUE-EMPTY QUEUE-GET QUEUE-ADD message_for_user FIN_CHECK_FOR_ESTABLISHED_OR_SYN_RECEIVED_STATES PROCESS_A_FIN PROCESS_A_FIN +--------------+--------------+------------------+ SEND_A_PIGGYBACKED_ACK QUEUE_GET QUEUE_ADD_TO_FRONT message_for_user SEND_A_PIGGYBACKED_ACK +------------+---------------+------------+---------------+---------+ BUFFGET TCP_HEADER_FORMAT SEND_FROM_TRANSMIT_QUEUE send_ip QUEUE_ADD +--------------------------+----------+-------------------+ QUEUE_ADD_TO_FRONT TCP_ERROR PACK_BUFFER_INTO_BIT_STREAM SEND_FROM_TRANSMIT_QUEUE +----------+-------------+------+-----------------+ QUEUE_GET QUEUE_ADD send_ip PACK_BUFFER_INTO_BIT_STREAM +---------------+----------------------+ QUEUE_EMPTY QUEUE_ADD_TO_FRONT PROCESS_COMMON_ACK +-------------+-----------+--------------------+ SEND_A_PIGGYBACKED_ACK DELETE_FROM_RETRANS_Q SEND_FROM_TRANSMIT_QUEUE PROCESS_RESET_IN_DATA_ACCEPTING_STATES +--------------+----------+--------------------+ QUEUE_CLEAR TCB_CLEAR MESSAGE_FOR_USER SEND_A_FIN +-------------------+-------------+------------+---------+ PACK_BUFFER_INTO_BIT_STREAM MESSAGE_FOR_USER send_ip QUEUE_ADD +-------------+-----------+---------------+---------------------+ QUEUE_CLEAR QUEUE_SIZE TCP_HEADER_FORMAT BUFFGET START_TIMER TCP_ERROR INSERT_TEXT_IN_BUFFER TCP_ERROR File Names in order of compilation for TCP/IP(WICAT) (TCP source files) Source Filename Symbol Filename Package name --------------- --------------- ------------ 1 RTC.TXT TREALTIME.SYM T_REAL_TIME_CLOCK 2 BUFFER BUFFERDAT.SYM BUFFER_DATA 3 MODULO.TXT MODULO.SYM MODULO 4 IPGLB.TXT IPGLOBALS.SYM IP_GLOBALS 5 TIMER.TXT REALTIMEC.SYM REAL_TIME_CLOCK_AND_DATE 6 SUBNETCAL.TXT SUBNETCAL.SYM SUBNET_CALLS 7 NCOMMIP.TXT WITHIPCOM.SYM WITH_IP_COMMUNICATE 8 UNPACK.TXT IPUNPACKA.SYM IP_UNPACK_AND_PACK_UTILITIES 9 TCPGLBDAT.TXT TTCPGLOBA.SYM T_TCP_GLOBAL_DATA_STRUCTURES 10 NCOMM.TXT WITHTCPCO.SYM WITH_TCP_COMMUNICATE 11 NCOMMU1.TXT WITHUSERC.SYM WITH_USER_COMMUNICATE 12 ICMP.TXT UTILITIES.SYM UTILITIES_FOR_ICMP 13 REASSEM.TXT REASEMBLY.SYM REASEMBLY_UTILITIES 14 TCPQUEUE.TXT QUEUES.SYM QUEUES 15 LCNKEEP.TXT TCBALLOCA.SYM TCB_ALLOCATOR 16 IPARRIVE.TXT IPARRIVEP.SYM IP_ARRIVE_PROCESSING 17 TCPGLOBALS.TXT TCPGLOBAL.SYM TCP_GLOBALS 18 IPCNTSND.TXT INTERNETP.SYM INTERNET_PROTOCOL_CONTROL_ AND_SEND_PROCESSING 19 PER1B.TXT TTCPARRIV.SYM T_TCP_ARRIVES1 20 PER1.TXT TCPARRIVE.SYM TCP_ARRIVES_PERIPHERALS 21 SEGARIVE1.TXT TCPSEGARR.SYM TCP_SEG_ARRIVE 22 SEGARIVE.TXT TCPSEGMEN.SYM TCP_SEGMENT_ARRIVES_PROCESSING 23 TCPUTIL1.TXT TTCPUTILI.SYM T_TCP_UTILITIES 24 TCPUTIL.TXT TTCPCONTR.SYM T_TCP_CONTROLLER_UTILITIES 25 TCPCONT2.TXT TCPCONTRO.SYM TCP_CONTROLLER_TASK 26 SUBCONTR1.TXT SUBNETCON.SYM SUBNET_CONTROLLER_TASK 27 FATCAT.TXT File Names in order of compilation for TCP/IP(VAX DEC/Ada) Source Filename Package name 1 BUFFER_.ADA BUFFER_DATA 2 BUFFER.ADA BUFFER_DATA 3 IPGLB_.ADA IP_GLOBALS 4 VMODULO_.ADA MODULO 5 VMODULO.ADA MODULO 6 RTCLKDAT_.ADA REAL_TIME_CLOCK_AND_DATE 7 RTCLKDAT.ADA REAL_TIME_CLOCK_AND_DATE 8 IP_TCP_.ADA IP_TCP 9 IP_TCP.ADA IP_TCP 10 SUBNET_CALLS_.ADA SUBNET_CALLS 11 SUBNET_CALLS.ADA SUBNET_CALLS 12 TCPGLBDAT_.DAT T_TCP_GLOBAL_DATA_STRUCTURES 13 LCNKEEP_.ADA TCB_ALLOCATOR 14 LCNKEEP.ADA TCB_ALLOCATOR 15 NCOMM_.ADA WITH_TCP_COMMUNICATE 16 NCOMM.ADA WITH_TCP_COMMUNICATE 17 UNPACK_.ADA IP_UNPACK_AND_PACK_UTILITIES 18 UNPACK.ADA IP_UNPACK_AND_PACK_UTILITIES 19 TCP_QUEUE_.ADA QUEUESA 20 TCP_QUEUE.ADA QUEUES 21 TCP_Q_.ADA TCP_Q_TASK 22 TCP_Q.ADA TCP_Q_TASK 23 TCP_TO_ULP_.ADA TCP_TO_ULP_COMMUNICATE 24 TCP_TO_ULP.ADA TCP_TO_ULP_COMMUNICATE 25 TCP_ULP_GET_.ADA GET_MESSAGES_FROM_ULP 26 TCP_ULP_GET.ADA GET_MESSAGES_FROM_ULP 27 SEND_IP_TASK_.ADA SEND_IP_TASK 28 SEND_IP_TASK.ADA SEND_IP_TASK 29 TCP_GLOBALS_.ADA TCP_GLOBALS 30 VTCP_GLOBALS.ADA TCP_GLOBALS 31 ICMP_.ADA UTILITIES_FOR_ICMP 32 ICMP.ADA UTILITIES_FOR_ICMP 33 REASSEM_.ADA REASEMBLY_UTILITIES 34 REASSEM.ADA REASEMBLY_UTILITIES 35 PER1_.ADA TCP_ARRIVES_PERIPHERALS 36 PER1.ADA TCP_ARRIVES_PERIPHERALS 37 IPARRIVE_.ADA IP_ARRIVE_PROCESSING 38 IPARRIVE.ADA IP_ARRIVE_PROCESSING 39 SEGARRIVE_.ADA TCP_SEGMENT_ARRIVES_PROCESSING 40 SEGARRIVE.ADA TCP_SEGMENT_ARRIVES_PROCESSING 41 IP_FROM_SUBNET_TASK_.ADA IP_FROM_SUBNET_TASK 42 IP_FROM_SUBNET_TASK.ADA IP_FROM_SUBNET_TASK 43 TCP_UTILITIES_.ADA T_TCP_CONTROLLER_UTILITIES 44 TCP_UTILITIES.ADA T_TCP_CONTROLLER_UTILITIES 45 TCP_CONTROLLER_.ADA TCP_CONTROLLER_TASK 46 TCP_CONTROLLER.ADA TCP_CONTROLLER_TASK --:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: --ip.man --:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 1. INTERNET PROTOCOL 1.1 Functional Description. The Internet Protocol is designed for use in interconnected networks of packet-switched computer communication facilities. IP provides an internet datagram service using the facilities of the intranetwork datagram protocol. IP does not provide end-to-end data reliability, flow control, sequencing or other services that are usually found in host-to-host protocols. It can provide various types and qualities of service by utilizing the services of its supporting networks. This version of the Internet Protocol conforms to RFC:791, the Internet Protocol Darpa Internet Program Protocol Specification from September 1981. It is designed so that it is effectively decoupled from the layers above and below it. The interface design allows different layers of protocol to be used above and below IP with no significant impact. This implementation also contains the Internet Control Message Protocol. IP, by virtue of its design, can be run as a detached process or as a procedure which is called by a program. This flexibility enables IP's use in different scenarios. 1.2 Using IP. IP communicates with upper and lower level protocols via queues, request primitives, and response primitives. Communications between IP and TCP running on VMS is via a shared data structure. The interface to Ethernet is through mailboxes. Communications between IP and its upper and lower levels on the WICAT are through shared resources. It should be noted that the interface between TCP and IP is the same for both the VMS, and WICAT versions of the IP implementation. The data structure for IP datagrams was described in section 1.3.4.1 c. of the TCP users manual. IP encapsulates a header on messages passed down to it from TCP and removes the IP header from messages it receives. The ICMP mechanism provides the host with the following information: 1. NET UNREACHABLE : The IP sent a datagram that cannot be reached for the following reasons: net unreachable; host unreachable; protocol unreachable; port unreachable; fragmentation needed and don't fragment flag is set; source route failed. The above messages are then passed to the ULP for notification of the problem. 2. SOURCE QUENCH MESSAGE : All redirect messages are supported. The present implementation passes the message on to the ULP. 4. ECHO MESSAGE : Upon reception of an echo message, ICMP will return the message to the sender. 5. PARAMETER PROBLEM MESSAGE : At present the ULP is only notified that a parameter parameter has occurred. The reassembly mechanism of IP has been implemented as specified in MIL-STD 1777. As fragments are received from the subnet, the data portion of the datagram is stored in a reassembly queue. Upon successful reassembly within a specified timeout window the datagram is forwarded to the TOTCPQUEUE. This IP implementation does not support fragmentation (gateway function). The IP is event driven with input from the TOIPQUEUE. This queue receives input from both TCP and Ethernet. Rationale for one queue was for efficiency considerations. 1.3 Hierarchy Diagram for the INTERNET Protocol. IPCONTROLLER +-----------------------+---------------------+-------------+ SEND_IP IP_DATAGRAM_ARRIVE IP_ERROR_HANDLER ip_wait +-------+--------------+-------------+ BUFFREE CHECKSUM message_for_tcp UNPACK +--------+-------+------------+------------+-----------------------+ OPTION_CHECKER CPM_SEND DESTINATION_SCHECK BUFFREE PACK_BUFFER_INTOBIT_STREAM +---------------+---------+ UNCHECKED_CONVERSION CHECKSUM 1.3 Hierarchy Diagram For The INTERNET Protocol. IPCONTROLLER +-----------------------+---------------------+-------------+ SEND_IP IP_DATAGRAM_ARRIVE IP_ERROR_HANDLER ip_wait +-------+--------------+-------------+ BUFFREE CHECKSUM message_for_tcp UNPACK +--------+-------+-----------+------------+-----------------+ OPTION_CHEKER CPM_SEND DESTINATION_CHECK BUFFREE PACK_BUFFER_INTO_BIT_STREAM +----------------+----------+ UNCHECKED_CONVERSION CHECKSUM File Names in order of compilation for TCP/IP(WICAT) (TCP) source files) Source Filename Symbol Filename Package name --------------- --------------- ------------ 1 RTC.TXT TREALTIME.SYM T_REAL_TIME_CLOCK 2 BUFFER BUFFERDAT.SYM BUFFER_DATA 3 MODULO.TXT MODULO.SYM MODULO 4 IPGLB.TXT IPGLOBALS.SYM IP_GLOBALS 5 TIMER.TXT REALTIMEC.SYM REAL_TIME_CLOCK_AND_DATE 6 SUBNETCAL.TXT SUBNETCAL.SYM SUBNET_CALLS 7 NCOMMIP.TXT WITHIPCOM.SYM WITH_IP_COMMUNICATE 8 UNPACK.TXT IPUNPACKA.SYM IP_UNPACK AND PACK UTILITIES 9 TCPGLBDAT.TXT TTCPGLOBA.SYM T_TCP_GLOBAL_DATA_STRUCTURES 10 NCOMM.TXT WITHTCPCO.SYM WITH_TCP_COMMUNICATE 11 NCOMMU1.TXT WITHUSERC.SYM WITH_USER_COMMUNICATE 12 ICMP.TXT UTILITIES.SYM UTILITIES_FOR_ICMP 13 REASSEM.TXT REASEMBLY.SYM REASEMBLY_UTILITIES 14 TCPQUEUE.TXT QUEUES.SYM QUEUES 15 LCNKEEP.TXT TCBALLOCA.SYM TCB_ALLOCATOR 16 IPARRIVE.TXT IPARRIVEP.SYM IP_ARRIVE_PROCESSING 17 TCPGLOBALS.TXT TCPGLOBAL.SYM TCP_GLOBALS 18 IPCNTSND.TXT INTERNETP.SYM INTERNET_PROTOCOL_CONTROL_- AND_SEND_PROCESSING 19 PER1B.TXT TTCPARRIV.SYM T_TCP_ARRIVES_1 20 PER1.TXT TCPARRIVE.SYM TCP_ARRIVES_PERIPHERALS 21 SEGARIVE1.TXT TCPSEGARR.SYM TCP_SEG_ARRIVE 22 SEGARIVE.TXT TCPSEGMEN.SYM TCP_SEGMENT_ARRIVES_PROCESSING 23 TCPUTIL1.TXT TTCPUTILI.SYM T_TCP_UTILITIES 24 TCPUTIL.TXT TTCPCONTR.SYM T_TCP_CONTROLLER_UTILITIES 25 TCPCONT2.TXT TCPCONTRO.SYM TCP_CONTROLLER_TASK 26 SUBCONTR1.TXT SUBNETCON.SYM SUBNET_CONTROLLER_TASK 27 FATCAT.TXT File Names in order of compilation for TCP/IP(VAX DEC/Ada) Source Filename Package name --------------- ------------ 1 BUFFER_.ADA BUFFER_DATA 2 BUFFER.ADA BUFFER_DATA 3 IPGLB_.ADA IP_GLOBALS 4 VMODULO_.ADA MODULO 5 VMODULO.ADA MODULO 6 RTCLKDAT_.ADA REAL_TIME_CLOCK_AND_DATE 7 RTCLKDAT.ADA REAL_TIME_CLOCK_AND_DATE 8 IP_TCP_.ADA IP_TCP 9 IP_TCP.ADA IP_TCP 10 SUBNET_CALLS_.ADA SUBNET_CALLS 11 SUBNET_CALLS.ADA SUBNET_CALLS 12 TCPGLBDAT_.DAT T_TCP_GLOBAL_DATA_STRUCTURES 13 LCNKEEP_.ADA TCB_ALLOCATOR 14 LCNKEEP.ADA TCB_ALLOCATOR 15 NCOMM_.ADA WITH_TCP_COMMUNICATE 16 NCOMM.ADA WITH_TCP_COMMUNICATE 17 UNPACK_.ADA IP_UNPACK_AND_PACK_UTILITIES 18 UNPACK.ADA IP_UNPACK_AND_PACK_UTILITIES 19 TCP_QUEUE_.ADA QUEUES 20 TCP_QUEUE.ADA QUEUES 21 TCP_Q_.ADA TCP_Q_TASK 22 TCP_Q.ADA TCP_Q_TASK 23 TCP_TO_ULP_.ADA TCP_TP_ULP_COMMUNICATE 24 TCP_TO_ULP.ADA TCP_TO_ULP_COMMUNICATE 25 TCP_ULP_GET_.ADA GET_MESSAGES_FROM_ULP 26 TCP_ULP_GET.ADA GET_MESSAGES_FROM_ULP 27 SEND_IP_TASK_.ADA SEND_IP_TASK 28 SEND_IP_TASK.ADA SEND_IP_TASK 29 TCP_GLOBALS_.TXT TCP_GLOBALS 30 VTCP_GLOBALS.TXT TCP_GLOBALS 31 ICMP_.ADA UTILITIES_FOR_ICMP 32 ICMP.ADA UTILITIES_FOR_ICMP 33 REASSEM_.ADA REASEMBLY_UTILITIES 34 REASSEM.ADA REASEMBLY_UTILITIES 35 PER1_.ADA TCP_ARRIVES_PERIPHERALS 36 PER1.ADA TCP_ARRIVES_PERIPHERALS 37 IPARRIVE_.ADA IP_ARRIVE_PROCESSING 38 IPARRIVE.ADA IP_ARRIVE_PROCESSING 39 SEGARIVE_.ADA TCP_SEGMENT_ARRIVES_PROCESSING 40 SEGARIVE.ADA TCP_SEGMENT_ARRIVES_PROCESSING 41 IP_FROM_SUBNET_TASK_.ADA IP_FROM_SUBNET_TASK 42 IP_FROM_SUBNET_TASK.ADA IP_FROM_SUBNET_TASK 43 TCP_UTILITIES_.ADA T_TCP_CONTROLLER_UTILITIES 44 TCP_UTILITIES.ADA T_TCP_CONTROLLER_UTILITIES 45 TCP_CONTROLLER_TASK_.ADA TCP_CONTROLLER_TASK 46 TCP_CONTROLLER_TASK.ADA TCP_CONTROLLER_TASK --:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: --ftp.man --:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 1. FTP 1.1 Functional Description. FTP (File Transfer Protocol) is designed to transfer files from one computer system to another despite differences in the underlying file systems. The files are transferred according to user specified parameters which indicate the mode of transfer, file type and file structure. 1.2 Using FTP. 1.2.1 Command Descriptions. The first four characters of a command are significant and must be typed in upper case. 1. CALL The call command is used to establish connection with the remote computer system. It has the format CALL net-address where net-address has the format v.w.x.y;z. For details of this format please see the TELNET user's guide. 2. EXIT The exit command is used to exit from FTP. It has the effect of logging the user off of any systems that may be logged in and then closing any data connections that may be open. This command really should be named QUIT to be more in keeping with the specification. 3. HELP The help command is used to send useful information about a remote computer system to the user. The information includes what commands are supported at the remote system and their syntax. It has the format HELP. 4. MODE The mode command is used to inform FTP which transfer mode is in effect. It has the format MODE argument where argument can be S)tream, B)lock, or C)ompressed. The stream mode transfers files as a continuous stream of data bytes. The block mode transfers files as a series of blocks. The compressed mode compresses the data for more efficient data transfers. Only the stream mode is currently supported. 5. NOOP The noop command does not effect any parameters or previously entered commands. It specifies no other action than for the remote computer system to send an OK reply. It has the format NOOP. 6. PASSword The password command is used to specify the user's password if one is required for a remote computer system's log on procedure. This command must be immediately preceded by the user command. It has the format PASS user-password where user-password is a valid password string for the remote computer system. 7. PORT The port command is used to inform an FTP program running on a remote system to use a specified port for data transfer instead of its default port. This is useful when a user on computer 'C' wants to send files directly from computer 'A' to computer 'B.' It has the format PORT u.v.w.x.y;z where u.v.w.x represent the address of the FTP program to change its port and y;z represents the port number to be used. 8. RETRieve The retrieve command is used to transfer a file from a remote computer system to the local computer system. It has the format RETR Remote-file name Local-filename. The file is transferred according to the current MODE, STRU, and TYPE. 9. STORe The store command is used to transfer a file from the local computer system to a remote computer system. It has the format STOR Local-filename Remote-filename. The file is transferred according to the current MODE, STRU, and TYPE. 10. STRUcture The structure command is used to inform FTP about the file's structure. The file structure is how the file is represented internally on its host computer system. The structure command has the format STRUcture valid-file-structure where valid-file-structure is FILE, RECORD, or PAGE. File indicates that the file is considered to be a continuous stream of bytes with no internal structure. RECORD indicates that the file is composed of sequential records. PAGE indicates that the file is composed of individual indexed pages. Only FILE and RECORD structures are supported. 11. TYPE The type command is used to inform FTP about the file's representation. This representation includes how the bytes are represented as well as the type of carriage control used. The type command has the format TYPE byte-representation carriage-control. The byte-representation can be ASCII, EBCDIC, IMAGE, or LOCAL BYTE. ASCII indicate that the bytes are stored using standard ascii codes. EBCDIC indicate that the bytes are stored using standard EBCDIC codes. IMAGE indicates that the file is stored and transferred as contiguous bits and is useful for transferring binary data files. LOCAL BYTE indicates that the file is stored in logical bytes with a size that is specified by a second parameter instead of a carriage control field. Only the ASCII byte-representation is supported at this time. The carriage-control field indicates that type of carriage control used in the file. The carriage control field can be NON-PRINT, TELNET, or ASA. NON-PRINT indicates that no carriage control information needs to be stored in the file. NON-PRINT is the default value if the carriage control field is omitted. TELNET indicates that file contains ASCII/EBCDIC vertical format controls |cr , |LF , |NL , |VT , |FF . ASA indicates that the file contains ASA (FORTRAN) vertical format control characters. The carriage control field indicates the size of the logical byte to be used if LOCAL BYTE has been specified. In this case the field is in integer number which indicates the logical byte size. 12. USER The user command is used to log the user onto a remote system. The user command has the format USER user-name. If a remote system does not require a username then the user-name field can be omitted. If the remote system requires a password, the user will have to use the PASSword command after the USER command. If the user is currently logged in and a USER command is issued then FTP will log the USER off of the remote system and then log on under the new user-name. 13. QUIT The QUIT command is used to log the user off of the remote computer system without closing the connection to the remote system from the local system. Issuing a QUIT folowed by USER has the same effect as a QUIT while logged in. This command really should be named REINialize to be more in keeping with the specification. 1.2.2 Running FTP. 1. To invoke FTP, the user simply enters "RUN USERFTP" at the command level. FTP is then loaded and ready to use. 2. Prior to doing a file transfer the user must establish a connection to the remote computer system. This is accomplished via the CALL command. 3. After a connection has been established, the user should log onto the system, if necessary, using the USER command. 4. The user may choose to set certain system parameters at this time; specifically the type, mode, structure, and port to be used for a file transfer. These parameters are optional and depend on the computer systems being accessed. 5. Use either the STOR (to send a file) or RETR (to receive a file) command to transfer a file. 6. Use either the QUIT or USER command if you wish to change the directory you are logged in on without closing the connection. If you use QUIT then you will be logged off of the remote computer system but will still have a connection so that a USER command could be entered. If you use USER then you will be logged off of the current directory and prompted for a new directory name which you will be logged on to. 7. Once all the file transfers have been completed, the user should close the connection using the CLOS or EXIT command. Use CLOS if you wish to CALL another computer system and transfer more files. Use EXIT if you are finished with all file transfers and wish to exit from FTP. 1.2.3 Sample Session. 1. FTP <CR> 2. CALL ...1;26 <CR> This CALL command opens a connection to the computer system with a network address of ...1;26. Please see the TELNET specification for details of the network addresses. 3. USER SMITH <CR> This USER command logs the user onto the remote computer system under the username of SMITH. 4. STRU RECORD <CR> This STRUcture command informs FTP that the file to be transferred is composed of individual records. 5. TYPE ASCII NONPRINT <CR> This TYPE command informs FTP that the file to be transferred is composed of ASCII characters using NONPRINT carriage control. 6. MODE STREAM <CR> This mode command informs FTP that the file is to be transferred as a stream of bytes. 7. RETR DATA.TXT FILE.TEXT <CR> This RETRieve command informs FTP to copy the file DATA.TXT from the remote computer system to a local file named FILE.TEXT. 8. EXIT <CR> This EXIT command informs FTP that the user is finished and that it should close the connection to the remote computer system and then return to the operating system. 1.3 FTP Computer Program Overview. 1.3.1 Hardware. This implementation of FTP is targeted for a VAX 11/780 and Wicat work station. 1.3.2 Operating System. This implementation of FTP is targeted for VMS 4.1 and ROS version 2.1e - Labtek RTK 2.2. 1.3.3 Ada Compiler Implementation. This implementation of FTP is written for DEC Ada version 1.0 (VAX) and TeleSoft-Ada version 1.3 (WICAT). 1.3.4 Package Overview. Most of the FTP packages encapsulates one data type and the operations that are used on that type. There are two exceptions to this rule. The first exception is the command handlers. These packages contain procedures that effect the user/server PIs or user/server DTPs. This was done to limit the package sizes so that they were not excessively large and therefore inhibitive to compile. The second exception is the FTP global data types packages. These packages contain the basic types that are used throughout FTP including the command string format, reply format, and argument format. Functions and procedures to manipulate these types were not included in FTP because the types were rigidly outlined in RFC 765 specification. 1.3.4.1 Hierarchy Chart. ========================= Called routines ========================== +-------+ +-------+ ! Ftp- ! ! Ftp- ! ! user ! ! server! ! ! ! ! +-------+ +-------+ ========================= Command handlers ========================= +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ ! Ftp- ! ! Ftp- ! ! Ftp- ! ! Ftp- ! ! Ftp- ! ! Ftp- ! ! Ftp- ! ! usr- ! ! usr- ! ! usr- ! ! srv- ! ! srv# ! ! srv- ! ! srv- ! ! xfr ! ! pi ! ! dtp ! ! log ! ! dtp ! ! pi ! ! xfr ! +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ ========================= Command handler's utilities ========================= +-------+ ! Ftp- ! ! srv- ! ! uH ! +-------+ =========================== Ftp utilities =========================== +-------+ ! Ftp- ! ! Ut1 ! ! ! +-------+ ======================== Data processing packages ======================= +-------+ +-------+ +-------+ +-------+ ! Ftp- ! ! Ftp- ! ! Ftp- ! ! Ftp- ! ! cmd- ! ! file- ! ! rpl- ! ! site ! ! utl ! ! IO ! ! utl ! ! ! +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ ! Ftp- ! ! Ftp- ! ! Ftp- ! ! rcv- ! ! low- ! ! rpl- ! ! utl ! ! IO ! ! dat ! +-------+ +-------+ +-------+ +-------+ ! Ftp- ! ! cnv- ! ! cmd ! +-------+ =========================== Interfaces ========================= +-------+ +-------+ +-------+ ! Ftp- ! ! Ftp- ! ! Ftp- ! ! term ! ! tcp ! ! telnet! ! ! ! ! ! ! +-------+ +-------+ +-------+ ============================ Ftp global data types ============================ +-------+ +-------+ +-------+ ! Ftp- ! ! Ftp- ! ! Ftp- ! ! cmd ! ! types ! ! reply ! ! ! ! ! ! ! +-------+ +-------+ +-------+ 1.3.4.2 Package Descriptions. The following is a brief description of what each package contains and why it is a package. 1.3.4.2.1 Called Routines. The called routines are the upper most procedures in FTP. The FTP-user procedure is invoked on the system where the user is running. The FTP-server procedure is invoked on the remote system to process the user's commands. There are three primary differences between these two procedures. The first is where the commands are obtained. The second is the command handler that is called to process the command. The third is the way that exceptions are handled. 1.3.4.2.2 Command Handlers. The command handlers are the uppermost procedures that process specific commands. They are primarily concerned with the handshaking between the two computer systems using calls to lower level procedures to do the actual work. These lower level procedures perform functions which are independent of the calling upper level procedure (user or server). The command handlers are broken down into two sides: the user side, and the server side. The user side sends the commands and receives replies. The server side accepts commands and sends replies. The command handlers are contained in the following packages: 1. Ftp-usr-xfr. This package contains the procedures used by the user side to process commands that perform file transfers at the highest level of abstraction. These commands include: STORe and RETRieve. 2. Ftp-user-pi. This package contains the procedures used by the user side to process commands that do not directly effect file transfers. These commands include: NOOP, HELP, QUIT, USER, CALL, and CLOS. 3. Ftp-usr-dtp. This package contains the procedures used by the user side to process commands that effect file transfers. These commands include: TYPE, STRUcture, MODE, and PORT. 4. Ftp-srv-log. This package contains the procedures used by the server side to process commands that perform system login/logout activities. This package was created because of all the FTP commands, these will be the most system dependent. Consequently, this package can be changed as required without having to change any lower level packages common to other FTP packages. This is the only command handler package that does not have a counterpart on the user side. 5. Ftp-srv-dtp. This package is synonymous with Ftp-usr-dtp except that it is used by the server side. 6. Ftp-srv-pi. This package is synonymous with Ftp-usr-pi except that it is used by the server side. 7. Ftp-srv-xfr. This package is synonymous with Ftp-usr-xfr except that it is used by the server side. 1.3.4.2.3 Command Handler's Utilities. This package contains procedures that are used to send replies. These procedures should have been located in the Ftp-rpl-utl package because they all manipulate replies. They were included in a separate package, however, because the reply is actually sent. That requires access to the procedures in Ftp-cmd-utl which are used to send commands. As a result, Ftp-rpl-utl would have to have access to Ftp-cmd-utl and that was undesirable. 1.3.4.2.4 FTP Utilities. The Ftp-utl package contains the functions and procedures used by the user and server sides to access information which describes FTP's current state. All the information about FTP's state is contained in a single data type which was implemented as a private type to minimize the effects of changes. 1.3.4.2.5 Data Processing Packages. These packages contain the procedures to query about the current FTP implementation as well as to operate on commands, replies, and files. The first set of packages concentrates on commands and includes: 1. Ftp-cmd-utl. This package contains the procedures necessary to send and receive commands. 2. Ftp-rcv-utl. This package contains the procedures necessary to receive commands and parse them into their component parts. 3. Ftp-cnv-cmd. This package contains the procedures necessary to convert the commands from variable length strings into an enumerated type. It was desirable to use an enumerated type to keep track of the command being processed because the Ada language does not allow for convenient testing of variable length strings. The second set of packages performs file I/O and includes: 1. Ftp-file-io. This package contains procedures that perform file transfers as well as logical file operations. The file transfer procedures are used by both the user and server sides. 2. Ftp-low-io. This package is very system dependent. It provides procedures which are used in performing the logical file operations in Ftp-file-io. The third set of packages manipulates replies and includes: 1. Ftp-rpl-utl. 2. Ftp-rpl-dat. The last package, Ftp-site, keeps track of the current FTP implementation. It uses a private data type to record what parameters are implemented and which are not. The use of a private data type enforces hiding. 1.3.4.2.6 Interfaces. These three packages are highly system dependent. Each pacakge provides a logical interface to the host system. 1. Ftp-term. This package interfaces FTP to the user's terminal. By using an intermediate package for terminal I/O, portability is increased at the expense of a level of overhead. This was desirable because it allowed for localized modification if certain terminals or systems did not support standard Ada calls. 2. Ftp-tcp. This package interfaces FTP to TCP. It is used for all data transfers. The procedures provide the desired data access routines while hiding the actual TCP implementation. This greatly decreases the effects of changing TCPs. 3. Ftp-telnet. This package interfaces FTP to Telnet. It is used to send and receive all commands and replies. The procedures provide the desired access routines while hiding the actual Telnet implementation. This greatly decreases the effects of changing Telnet implementations. 1.3.4.2.7 Ftp Global Data Types. These packages contain data types that are fundamental to FTP and are consequently required by most FTP packages. 1. Ftp-cmd. This package contains constants and types which describe FTP commands. 2. Ftp-types. This package contains constant and types which describe FTP arguments. 3. Ftp-reply. This package contains constant and types which describe FTP replies. 1.3.4.3 File Names In Order Of Compilation. (Files needed to interface to TELNET); Source Filename Symbol Filename Package Name --------------- --------------- ------------ I PVIRTLPAC VIRTUALTR Virtual-transport-level II AUSERDPAC USERDATA User_data III SERVER_TELNET_ PACKAGE N/A (VAX) Server_telnet_package IV DEC_TN_TASKS N/A (VAX) Dec_tn_tasks (Files needed to interface to TCP); Source Filename Symbol Filename Package name (WICAT) --------------- --------------- ------------ A BUFFER BUFFERDAT Buffer-data B NCOMM (WICAT) WITHTCPCO With-tcp-communicate C NEW_NCOMMU WITHULPCO With-ulp-communicate (FTP source files) Source Filename Symbol Filename Package name (WICAT) --------------- --------------- ------------ 1 VT100 VT100 Vt100 2 MYDEBUGIO MYDEBUGIO My-debug-io 3 MYUTILS MYUTILITI My-utilities 4 FTPCMD COMMANDTY Command-types 5 FTPTYPES FTPTYPES Ftp-types 6 FTPRPL REPLYTYPE Reply-types 7 FTPTERM FTPTERMIN Ftp-terminal-driver 8 FTPTCP FTPTCP Ftp-tcp 9 FTPTELNET FTPTELNET Ftp-telnet 10 FTPCNVCMD FTPCONVER Ftp-convert-commands 11 FTPRCVUTL FTPRCVUTL Ftp-rcv-utils 12 FTPCMDUTL FTPCOMMAN Ftp-command-utilities 13 MYCNVT MYCONVERSI My-conversions 14 FTPLOWIO FTPLOWLEV Ftp-low-level-io 15 FTPFILEIO FTPFILEIO Ftp-file-io 16 FTPSITE SITEDETAI Site-details 17 FTPRPLDAT FTPREPLYD Ftp-reply-data 18 FTPRPLUTL REPLYUTIL Reply-utilities 19 FTPUTL FTPUTILIT Ftp-utilities 20 FTPSRVUTL SERVERUTI Server-utilities 21 FTPSRVLOG SERVERLOG Server-login-commands 22 FTPSRVDTP SERVERDTP Server-dtp-commands 23 FTPSRVPI SERVERPIC Server-pi-commands 24 FTPSRVXFR SERVERXFE Server-xfer-commands 25 FTPSERVER SERVERFTP Server-ftp 26 FTPUSRXFR USERXFERC User-xfer-commands 27 FTPUSRPI USERPICOM User-pi-commands 28 FTPUSRDTP USERDTPCO User-dtp-commands 29 FTPUSER USERFTP User-ftp 1.3.4.4 Package Dependencies Source Filename Depends on --------------- ---------- 1 VT100 - 2 MYDEBUGIO 1 3 MYUTILS - 4 FTPCMD - 5 FTPTYPES 4 6 FTPRPL 5 7 FTPTERM 4, 5, 6 8 FTPTCP 1, 2, 3, A, B 9 FTPTELNET 2, 3, 4, A, B, C, I, II, IV 10 FTPCNVCMD 4, 5, 7 11 FTPRCVUTL 4, 5, 7, 10 12 FTPCMDUTL 4, 5, 7, 9, 11 13 MYCNVT - 14 FTPLOWIO 2, 3, 4, 7, 13 15 FTPFILEIO 1, 2, 3, 8, 14 16 FTPSITE 5, 7 17 FTPRPLDAT 2, 4, 5, 6 18 FTPRPLUTL 2, 4, 5, 6, 7, 9, 17 19 FTPUTL 2, 5, 7, 9, 12, 16 20 FTPSRVUTL 2, 5, 6, 12, 18 21 FTPSRVLOG 2, 5, 9, 19, 20 22 FTPSRVDTP 5, 16, 19, 20 23 FTPSRVPI 5, 6, 18, 19, 20 24 FTPSRVXFR 2, 5, 8, 12, 15, 19, 20 25 FTPSERVER 2, 5, 9, 12, 19, 20, 21, 22, 23, 24, III 26 FTPUSRXFR 2, 5, 6, 7, 8, 12, 15, 18, 19 27 FTPUSRPI 5, 6, 7, 12, 16, 18, 19 28 FTPUSRDTP 2, 5, 6, 7, 12, 16, 18, 19 29 FTPUSER 5, 7, 12, 19, 26, 27, 28, III --:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: --smtp.man --:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: SIMPLE MAIL TRANSFER PROTOCOL USERS MANUAL PREFACE This is a preliminary document for general information purposes only. No guarantee is made of the validity of the information herein, some of it may be subject to change or simply incorrect. 1.0 INTRODUCTION The Simple Mail Transfer Protocol (SMTP) allows exchange of electronic mail between processes attached by a common transport service. SMTP consists of two protocol interpreter processes, one is the sending process, called the User-SMTP, and the other is the receiver, called the Server-SMTP. This implementation is designed for the User-SMTP to be controlled by a human operator (as opposed to a computer process), and the Server-SMTP is designed to be an autonomous process in a host. This document is divided accordingly into two parts, one for each process. The protocol, as implemented, is specified MIL-STD-1781, dated 10 May 1984. 2.0 USER SMTP PROCESS The User SMTP process (USMTP) is designed to operate much the same way as the DEC VAX/VMS MAIL utility, except that the receiver may be located in a different host which is attached to the network. The user is prompted for various data (receiver-host, receiver-names, etc.). The data is then formatted according to the SMTP requirements and transmitted. The software is designed to allow the user to transmit mail without knowledge of the SMTP itself. 2.1 Using USMTP. 2.1.1 Establish a Connection to the Remote Host. The user will be prompted for the name of the remote host. Currently the user must enter the DDN address. This is a string of the form: NETWORK.HOST. This format will be translated to the proper address for the transport protocol. Note that domain names are not currently supported (see section 2.5). USMTP will then display with some status information as the connection is opened and the USMTP perform the necessary protocol handshaking. 2.1.2 Identify Source. The sender will be prompted to enter the receiver names (RCPT). Multiple receivers are allowed (on the same host). As each name is entered, status information will be displayed as the remote host confirms that it can deliver the mail to the receiver (or denies delivery). The host format must be in the same format as expected for user names in the remote host. A nul line (cr) will terminate the list. At least one RCPT must be acknowledged by the remote host. 2.1.4 Enter the Text. The test is entered by the operator at the keyboard. Note that mailing files is not currently supported (see section 2.5). Terminate the text with an escape and a carriage return. Status information is displayed when the SSMTP confirms reception. 2.1.5 Exit or Open Another Connection. The user will be prompted to send more mail, or exit. The user will be prompted to send more mail, or ext. 2.2 Example Session. $ SMTP SMTP VERSION 1.0 ENTER DESTINATION HOST NAME (NET.HOST)- 26.103 <CR> 220 TECR MAIL SERVICE READY 250 OK PLEASE ENTER YOUR USER NAME - HIGGINS@ECI<CR> RCPT- CONTR23<CR> 250 IK RCPT- <CR> 354 BEGIN MAIL PLEASE ENTER DATA, END WITH <ESC> <cr> THIS IS SOME SAMPLE MAIL... Blah Blah Blah ..... ALL FOR NOW <ESC> <CR> 220 IK 221 CLOSING CONNECTION CLOSED $ 2.3 USMTP OPERATIONS This section describes the functional characteristics of the USMTP in greater detail than the previous section. USMTP has been designed to separate the user from the details of the protocol itself as much as possible. This section details the interaction of the steps outlined in the previous section in relation to the actual protocol interaction and processing. 2.3.1 Initial State. In this state, the USMTP prompts for a distant host name. It then waits until a string is input terminated by a <CR> . Then the procedure translates host name to address is called to examine the name and determine if it is a known host name. Currently it parses the string assuming it is of the form NETWORK.HOST where both fields are decimal addresses. It then translates that to the complete internet address for the well-known socket for SMTP at the host (i.e., NETWORK..25.HOST). USMTP will then send an active open to that port by calling tcp, and then wait for an open message from tcp. Error messages from tcp will cause a tcp error exception. After a successful open, the SMTP command HELO will be sent with the local host name. This host name is hard coded into a constant string; see section 2.5 for details. USMTP will then wait for the correct reply for a HELO command (i.e., 250) to be received. It will then prompt the user for his name, and send it in a MAIL command. USMTP will then wait for the correct reply (250). The two SMTP processes are then in synchronization. 2.3.2 Receipt List. In this state, USMTP prompts for the receiver name. It then sends the name in a RCPT command, and waits for a response. It will then print out the response, and prompt for another receiver. A nul line terminates the list. At least on RCPT command must elicit a will-deliver reply (250-251) for the user to exit this state. 2.3.3 Data State. First, a DATA command is sent to the SSMTP, and then the USMTP awaits the start-mail response (354). The user is prompted for data lines and these are sent, line by line to the SSMTP. Each line is examined for a starting period, and if one is present the line is padded by a blank. The end of text sequence is the escape key followed by the <CR> . Upon detection of this sequency, an end-of-data indicator is sent to the SSMTP. The delivery-ok response is then expected by the USMTP. Note that the escape sequence is used here because of difficulty resetting the default input file in textio. If this problem is resolved, the end-of-data will be an end-of-file mark (Z), which will correspond to the vms mail utility and will also make extension to non-interactive data entry much easier. 2.3.4 Quit State. A QUIT command is then sent to the SSMTP and the TCP connection is closed. The closed message is expected from tcp. The user is then prompted for the choice to exit or return to idle state. 2.4 Detailed Program Description. The USMTP is implemented in seven packages, and utilizes five network support packages. The usmtp packages are usmtpconnections, usmtpnetwork,, usmtprcpt, usmtpreplies, usmtptext, usmtputils and usmtp. The four network support packages are buffer, vmodulo, tcpglobals, ipglobals, and withulpcommunicate. These support packages are not documented here, see the tcp documentation for more details. The package usmtputils contain the global constants and exceptions used throughout the implementation. Among these are the exceptions raised at various places in response to abnormal conditions (tcpreset, userreset, etc.), the reply codes which are sent by the ssmtp, and implementation restricted data structures, such as the maximum line length allowed. The package usmtp network provides the basic functions of the network transport service. These include opening a connection, sending data, receiving data, closing a connection, and aborting a connection. The implementation is vax-top dependent, but the interface is designed to provide a transport-independent service. The package usmtpconnections provides the routines to establish an smtp connection including performing the specified handshaking, and to properly termiante the smtp connection. The package usmtprcpt contains the procedures to send rcpt commands and verify the response to the rcpt. At least one rcpt must be properly aknowledged, and a <CR> .<CR> , but could be easily changed to any other desirable character (such as escape). The package usmtpreplies contains the routines to get the ssmtp reply from the network and check for abnormal conditions (such as sudden transport close, bad command reply from ssmtp, etc.). The usmtp is the main package which controls the usmtp session. It contains the main procedure which is called from the DCL level to invoke the usmtp. 2.5 User SMTP Limitations, Improvements, Etc.. This section discusses the limitations of the implementation of USMTP. 2.5.1 Names. Currently, only very limited naming is supported. The procedure translate_name(name : in string <>, net_number : out integer, host_number : out integer, valid_name : out boolean) ; will accept a string in the fomrat net-host only. Some future upgrade will support domains, aliases, etc. by changing the implementation of this procedure. 2.5.2 Text Input. Currently, only interactive input from the keyboard is supported. An escape is used to terminate. Modification could be included to support sending files. Utilizing the escape code (rather than an end-of-file) avoids the necessity of a reset to the default input file after the end of text. This may be changed in the next release. 2.5.3 Host and User name. Currently, the host name is hard-coded into the procedure sendhelo. To change this, simply modifying the string and recompiling the enclosing package will suffice. A modification could allow the code to perform a system call to retrieve the host's network name. Currently, the user is prompted for his name. This could be modified to allow the code to perform a system call to retrieve the host's network name. 3.0 SERVER SIMPLE MAIL TRANSFER PROTOCOL INTERPRETER The server simple mail transfer protocol interpreter (SSMTP) is the peer process to the USMTP which is responsible for receiving and delivering electronic mail. The SSMTP sums as an autonomous process which waits for activation by a USMTP. The mail exchange process is controlled by the USMTP. Once installed, the SSMTP requires no intervention by human operators. 3.1 Operation Once Initialized. The SSMTP requests a passive open on the SSMTP well-known socket (port 25). When an open message is received from tcp, the SSTP will await a HELO command from the USMTP, and save the host name for the received message. It will respond with a helo-ok response. It will then await the MAIL command from the USMTP and save the sender-name string. Send-or-mail (SOML) will also be accepted, send (SEND) or send-and-mail (SAML) will not be accepted. The SSMTP will then await the RCPT list. Each RCPT will be verified for a valid local-user. If the user is local, a RCPT-ok will be sent, otherwise a RCPT-not-ok will be sent. A DATA command will terminate the list. Once a DATA command is received, a begin-xmit response will be sent. The SSMTP will then buffer each line as they are received. At the end-of-test, the mail will be delivered. The SSMTP will then await the MAIL command or the QUIT. 3.2 Implementation Details. This section outlines some further details of the SSMTP. 3.2.1 User Lists. Currently the user list is used for verifying the receiver name in a RCPT command. This list is maintained in the package delivertouser, and is accessed by calling verify_user(user_name : string <>, user_is_local : boolean); A later refinement would implement the procedure with an os call to validate the name. 3.2.2 Mail Delivery. Mail is currently delivered by opening a file named smtpmail.txt writing the mail to it. This is done in the procedure delivermail. A DCL command procedure is used to allow the VMS system mailer to deliver the mail to the user. This DCL command will handle multiple user names and deliver a copy to each, and will handle multiple mail entries. 3.3 Detailed Program Description. SSMTP is implemented in eight packages, and uses five additional packages for network support. The SSMTP implementation packages are ssmtp, ssmtpdeliver, ssmtptext, ssmtprcpt, ssmtpconnections, ssmtpreplies, ssmtpconnections, ssmtpglobals. the ssmtpglobals package include the implementation restricted data structures and other widely used exceptions and types. The ssmtptransport contains the routines to interface to the transport service (TCP) to provide basic communication functions. These include listening on a passive connection, receiving data, sending data, closing the connection, and aborting the connection. These routines may raise various exceptions on abnormal conditions, such as unexpected connection closes. The ssmtpreplies package contains routines to format the various replies sent by ssmtp. These include the ready message, helo ok, mail ok, rcpt ok, rcpt not ok, out of buffer space, data ok, data complete ok, quit ok, and bad command format. These replies are sent to the transport package procedures for buffering and transmission. The ssmtpconnections package contains the procedures to establish the ssmtp data connection and perform the opening handshaking. It also handles the helo command. The ssmtprcpt package contains the procedures to handle the rcpt command. The rcpt-name is looked up in a local table contained in this package. If the name is in the table, a rcpt ok reply is sent. If not, a rcpt not ok is sent. The ssmtp text package contains the procedures to receive and buffer the mail text. It scans the input until an end-of-mail is received, i.e., <CR> .<CR> sequence.. The ssmtpdeliver package contains the procedure to write the mail into a file for later delivery. Currently it opens two files, one with a list of rcpt names, and the other with the data. A DCL command procedure is included which will invoke the DCL mail utility to actually deliver the mail to the recipients. By using the mail facility, the ssmtp procedure can run as an unprivileged process, but still move the mail to various other process files. The mail facility cannot be called from procedures, only from DCL-level, and so a command procedure is used rather than an Ada procedure. It is assumed that the deliver command job could be run separately as a batch job, or put into a loop together with the ssmtp itself. Finally, the ssmtp package contains the main procedures which controls the mail session. It runs in a loop, waiting for mail, and then processing it. --:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: --telnet.man --:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 1. TELNET 1.1 Functional Description. The TELNET Protocol provides a general bi-directional, byte-oriented communications facility allowing a standard method of interfacing terminal devices or terminal oriented processes together. This implementation is based on the Network Working Group Request for Comments: 854, "TELNET Protocol Specification," May 1983. 1.2 Using TELNET. 1.2.1 Command Descriptions. Only the first character in each word of the command is significant. All commands are preceded by the '@' symbol followed immediately by the first word of the command. Other command words follow and must be separated from each other by at least once space. If the user desires sending the '@' symbol as data, the character must be doubled (typed twice with no intervening spaces). All commands are terminated with a carriage return. Commands may be in upper or lower case but must be consistent with respect to case within a single command. If an incorrect command is entered, TELNET will respond with "bad" and an ascii bell. a. Valid Command Format Examples. 1. @SEND ARE YOU THERE CR| 2. @S A Y T CR| (equivalent to the above command) 3. @suppress go-ahead local CR| 4. @s g 1 CR| (short form of above) b. INVALID COMMAND FORMAT EXAMPLES: 1. @ SEND ABORT OUTPUT CR| (space between @ and first word of command) 2. @sendbreak (no space between command words) 3. @send SYNCH (mixed CASES) 1. CLOSE The CLOSE command closes a previously opened TELNET connection. The response message to a successful close command is "connection closed." 2. ECHO LOCAL The ECHO LOCAL command will request the local TELNET to echo data characters received from the remote TELNET back to that remote TELNET. As the remote TELNET may or may not agree to this option, the success or failure of this request will be reported when known. If the request was denied, the side of the connection responsible for the denial is identified. Note: TELNET will not allow remote echoing on both sides of the connection at once as this would imply an endless loop of retransmissions. If one side of the TELNET connection is performing remote echoing and both sides have agreed to suppress sending the TELNET GO-AHEAD, then TELNET will go into character-at-a-time instead of the default line-at-a-time transmission mode. 3. ECHO REMOTE The ECHO REMOTE command will request the remote TELNET to echo data characters received from the local TELNET back to the local TELNET. As the remote TELNET may or may not agree to this option, the success or failure of this request will be reported when known. If the request was denied, the side of the connection responsible for the denial is identified. Note: TELNET will not allow remote echoing on both sides of the connection at once as this would imply an endless loop of retransmissions. If one side of the TELNET connection is performing remote echoing and both sides have agreed to suppress sending the TELNET GO-AHEAD, then TELNET will go into character-at-a-time instead of the default line-at-a-time transmission mode. 4. OPEN net .host .logical-host .imp ;port The OPEN command allows the user to establish a connection to a remote TELNET. The parameter list after the OPEN command specifies the ARPANET-type network address of the remote TELNET's host computer. net# : This is the network number. The default is 10, the ARPANET. host# : This is the host number on the IMP. The default is zero. logical-host# : This is the logical host number. The default is zero. imp# : This is the IMP number the remote host is connected to. This number must be specified as there is no default. port# : This is the TCP port to which the connection will be made. The default is 23, TELNET. This parameter is optional. If the default value of a parameter is desired, enter a period after the missing parameter. For example, "@0 ...1" opens a connection to network number 10, host number 0, logical host number 0, IMP number 1, and TCP port number 23. It is equivalent to "@0 10.0.0.1;23". 5. RESET This command ensures the transport level connection is closed and resets all buffers and state information to start-up/default status. 6. STATUS This command returns status information about the transport level connection. 7. SEND ABORT OUTPUT This command allows the current process to (appear to) run to completion while not sending the output to the user. Only TELNET commands that can be processed in a timely manner will continue to be processed. 8. SEND ARE YOU THERE This command causes the remote TELNET to return a message indicating the remote TELNET is operational. 9. SEND BREAK This code provides a signal outside the USASCII set which is currently given local meaning within many systems. It indicates the "break" or "attention" key was hit. It is not a synonym for the Interrupt Process (IP) standard representation. 10. SEND ERASE CHARACTER This command instructs the remote user process to delete the last undeleted character from the stream of data being supplied by the user. 11. SEND ERASE LINE This command instructs the remote user process to delete the last undeleted line from the stream of data being supplied by the user. 12. SUPPRESS GO-AHEAD LOCAL The default I/O mode of TELNET is half duplex. This option can be used to increase efficiency on a full duplex terminal or I/O device by putting the local TELNET in full duplex mode. This option should not be used on a half duplex "lockable" keyboard terminal. As the remote TELNET may or may not agree to this option, the success or failure of this request will be reported when known. If one side of the TELNET connection is performing remote echoing and both sides have agreed to suppress sending the TELNET GO-AHEAD, then TELNET will go into character-at-a-time instead of the default line-at-a-time transmission mode. 13. SUPPRESS GO-AHEAD REMOTE The default I/O mode of TELNET is half duplex. This option can be used to increase efficiency on a remote full duplex terminal or I/O device by putting the remote TELNET in full duplex mode. This option should not be used on a remote half duplex "lockable" keyboard terminal. As the remote TELNET may or may not agree to this option, the success or failure of this request will be reported when known. If one side of the TELNET connection is performing remote echoing and both sides have agreed to suppress sending the TELNET GO-AHEAD, then TELNET will go into character-at-a-time instead of the default line-at-atime-transmission mode. 14. SEND INTERRUPT PROCESS Many systems provide a function which suspends, interrupts, aborts, or terminates the operation of the user process. The IP is the standard representation for this function. This is likely to be utilized by users who have an unwanted or runaway process. 15. SEND SYNCH This command will essentially eliminate all data already received by the remote but not processed. 16. QUIT ECHO LOCAL This command will stop the local TELNET from echoing characters to the remote TELNET. 17. QUIT ECHO REMOTE This command will stop the remote TELNET from echoing characters to the local TELNET. 18. QUIT SUPPRESS GO-AHEAD LOCAL This command will stop the local TELNET from suppressing the transmission of the TELNET GO-AHEAD signal. 19. QUIT SUPPRESS GO-AHEAD REMOTE This command will stop the remote TELNET from suppressing the transmission of the TELNET GO-AHEAD signal. 1.2.2 Running TELNET. 1. To invoke TELNET, the user enters TELNET at the command level. 2. Desirable non-default TELNET options that the user wishes to have at the establishment of a TELNET connection (if any) may be entered at this point. These options will then be negotiated at the subsequent establishment of a new connection. These options can also be established dynamically at any time during the TELNET session. Non-default options currently implemented are remote-echo and suppress go-ahead. The success or failure of the requested option negotiations is reported to the user as it becomes available. 3. To establish a TELNET connection, the user gives the open command and provides the net address he wishes to communicate with. 4. If the connection was successfully established, data will be transferred between the two ends of the connection. TELNET commands can also be entered at this time. 5. To terminate a connection, the user issues the close command. 6. Other connections could be established in a like manner. 7. To terminate the TELNET session all together, enter 'control-y' on the VAX and 'control-x' on the WICAT. 8. If on the VAX, enter "STOP" to terminate the TELNET process. 1.2.3 Sample Session. The sample session displays the operator entries in uppercase and the computers messages/responses in lower case. 1. TELNET CR| 2. @OPEN 1.2..3;4 CR| 3. connection established cr| 4. CR| 5. username: 6. NOSC CR| 7. password: 8. ADA CR| 9. welcome... 10. TY MYFILE.LIS CR| 11. Ada is the language of the future. cr| 12. because it is awesome. cr| 13. @CLOSE CR| 14. connection closed CR| 1.3 TELNET Computer Program Overview. 1.3.1 Hardware. This implementation is targeted for a VAX 11/780 and the Wicat workstation. 1.3.2 Operation System. The target operating systems are for VMS 4.1 and ROS version 2.1e - Labtek RTK 2.2. 1.3.3 Ada Compiler Implementation. The compilers used are TeleSoft-Ada version 1.3(WICAT) and DEC Ada version 1.0 (VAX.) 1.3.4 Package Overview. 1.3.4.1 Hierarchy Chart. ========================= INTERFACE TO THE CONTROLLER ========================= TELNET-PACKAGE ========================== APPLICATION PROTOCOL LEVEL ========================= APL-PACKAGE NVT-KEYBOARD-INPUT-PROCESSING TRANSPORT-LEVEL-INPUT-PROCESSING MESSAGE-PROCESSING ========================= PRESENTATION PROTOCOL LEVEL ========================= OPTION-NEGOTIATION VIURTUAL-TRANSPORT-LEVEL VIRTUAL-TERMINAL IO-TASKS ========================= DATA TYPES / DATA OPERATIONS ======================== USER-DATA =============================== TEST/DEBUG AIDS =============================== I-DEBUG-STATE-OUTPUT DEBUG-IO 1.3.4.2 Data Flow Diagrams. DATA FLOW FROM LOCAL TELNET TO REMOTE TELNET: --------------------------------- LOCAL TELNET -------------------------------- keyboard input --> IO-TASKS --> VIRTUAL-TERMINAL --> NVT-KEYBOARD-INPUT-PROCESSING --> VIRTUAL-TRANSPORT-LEVEL --> (ACTUAL LOCAL TRANSPORT LEVEL [TCP]) --> -------------------------------- REMOTE TELNET -------------------------------- (ACTUAL REMOTE TRANSPORT LEVEL [TCP] --> VIRTUAL-TRANSPORT-LEVEL --> TRANSPORT-LEVEL-INPUT-PROCESSING --> VIRTUAL-TERMINAL --> IO-TASKS --> printer output 1.3.4.3 Package Descriptions. TELNET-PACKAGE This package has the data types and data operations which are exported to the TELNET controller program to allow the controller to set up a user-control-block data structure needed by each TELNET user. It also contains the TELNET procedure itself which services a TELNET user. Additional procedures allow non-default TELNET options to be set or reset. TELNET-APL This package performs the high level processing associated with the TELNET Application Protocol Level (APL). NVT-KEYBOARD-INPUT-PROCESSING This package has subprograms to manage APL level processing of Network Virtual Terminal (NVT) keyboard input. TRANSPORT-LEVEL-INPUT-PROCESSING This package has APL subprograms used to process data input to the local TELNET from the remote TELNET. MESSAGE PROCESSING This package has APL subprograms used to process message input to the local TELNET from the local transport level. VIRTUAL-TERMINAL This package provides low level Network Virtual Terminal services and interfaces with the actual I/O device or process. VIRTUAL-TRANSPORT-LEVEL This package provides low level virtual transport level services and interfaces with the actual transport level. USER-DATA This package contains operations to examine and manipulate user APL state information and APL buffers. OPTION-NEGOTIATION This package contains subprograms to handle TELNET option negotiation. IO-TASKS This package has tasks to get/put characters from/to the actual terminal device's keyboard/printer. This is not used when TELNET is serving a process. DEBUG-IO This package is used for test/debug I/O as well as reporting exceptions during run time. I-DEBUG-STATE-OUTPUT This package is used for test/debug and outputs TELNET state information and data buffers. DEC-TN-TASKS (VAX) This package is used to make TELNET event driven instead of poling as on the single user WICAT. SERVER-TELNET-PACKAGE (VAX) This package contains a server-TELNET task type for exporting to a controller. 1.3.4.4 FILE NAMES (IN ORDER OF COMPILATION) Source Filename Symbol Filename Package Name --------------- --------------- ------------ 1 DEBUGIO DEBUGIO DEBUG-IO 2 PVIRTMPAC VIRTUALTE VIRTUAL-TERMINAL 3 TTYIO IOTASKS IOTASKS 4 AUSERDPAC USERDATA USER-DATA 5 PVIRTLPAC VIRTUALTR VIRTUAL-TRANSPORT-LEVEL 6 POPTNGPAC OPTIONNEG OPTION-NEGOTIATION 7 AMESSPAC MESSAGEPR MESSAGE-PROCESSING 8 ATRINPAC TRANSPORT TRANSPORT-LEVEL-INPUT- PROCESSING 9 AKEYBDPAC NVTKEYBOA OPTION-NEGOTIATION 10 APLPAC TELNETAPL TELNET-APL 11 TELNETPAC TELNETPAC TELNET-PACKAGE 12 IDEBUGSO IDEBUGSTA I-DEBUG-STATE-OUTPUT --------------------- VAX PACKAGES --------------------------- 2.5 DEC-TN-TASKS- 4.5 DEC-TN-TASKS 13 SERVER-TELNET-PACKAGE-,SERVER-TELNET-PACKAGE 14 USER-TELNET (controller procedure) 15 SERVER-TELNET (controller procedure) 1.3.4.5 PACKAGE DEPENDENCY CHART (WICAT) PACKAGE # SPECIFICATION DEPENDS ON BODY DEPENDS ON --------- ------------------------ --------------- 1 2 3 2 4 2 1 5 4,I,II,III 1 6 4 1,5 7 2,4,5 1 8 1,2,4,5,6 9 1,2,4,5,6 10 1,2,5,7,4,8,9 11 4,6 1,10 12 4 1 I (TCP PACKAGE) WITH-ULP-COMMUNICATE II (TCP PACKAGE) WITH-TCP-COMMUNICATE III (TCP PACKAGE) BUFFER-DATA