GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:ien:ien99

INDRA Note 753 IEN 99 May 3rd 1979

                   NI FTP: Summary and Assessment
                          P. L. Higginson
                           C. J. Bennett
             ABSTRACT: This note is a brief summary  of
             the  NI FTP, its design aims, and the ways
             in  which  those  aims  are  achieved.   A
             comparison  of  the NI FTP and the DIN FTP
             proposed for AUTODIN II  is  contained  in
             IEN 100.
                                   2

1. The NI FTP Protocol

   This section is a brief summary of the important features of the NI

FTP protocol.

   The NI FTP  was  written  by  a  committee  of  people  from  eight

different organisations in the UK who between them used a wide variety of computer systems and hardware. Computers used by the group were manufactured, among others, by DEC, IBM, ICL, GEC, PRIME and CTL. Drafts were widely circulated and discussed outside the design group. While the initial aim was to produce a protocol for transferring files across EPSS, "network independence" became an overriding aim. This was because it was realised that EPSS would shortly be replaced by a different, X25-based network, and because most of the eight organisations had multiple systems or their own local networks, and the ability to use the FTP in all these areas was desired. There are about 15 implementations in progress, of which 3 have so far exchanged files. UCL has a TOPS20/TENEX implementation which has transferred files across the ARPANET, and tests have begun on interworking with implementations in EPSS.

   The NI FTP is a two-party file  transfer  protocol.   The  transfer

occurs in two phases. In the first, the transfer is defined and the attributes of the data to be transferred are negotiated. In the second, the data is actually transferred. Three levels of protocol are recognised: level 0, which covers the negotiation of file transfer parameters; level 1, which handles error and flow control during the transfer, along with any data or time dependent changes in the file; and level 2, which is the actual transfer of data.

   The negotiation phase is simply structured to  be  an  exchange  of

file attributes between the two sides. These attributes define a common definition of the file and the transfer within a "conceptual filestore" supported by the two sides. During this phase, agreement is reached on such things as character code, file size, file name and access rights, all of which are regarded as attributes of the file within the conceptual file store. It is up to the two ends to map these attributes into locally acceptable forms for their actual filestores; if this cannot be done, the transfer may be rejected.

   The currently defined attributes cover a basic set of properties of

sequential files. This set can be easily extended, and facilities are provided to enable implementations to grow in an upwards compatible manner. Every attribute has a default value, which allows an implementor to construct a transfer facility as simple or as complex as desired, in the knowledge that his facility will be able to interact easily with more complex ones. This is possible because quoting an unknown attribute or unacceptable value for an attribute need not of itself cause a protocol error. During the negotiation phase, the more complex implementation will reduce its attribute set to one acceptable to the simpler one.

                                   3
   The data transfer phase can treat the data  totally  transparently,

but does provide a user record structure for text files if desired. It allows for data compression as an option, which can significantly reduce the amount of data actually transferred. Even if this is not used, the protocol overhead can be as low as 1 byte in 64. For text files, the existence of different degrees of formatting sophistication is recognised by allowing a set of common format effectors to be agreed in the negotiation phase. The data can be in a variety of codes, as agreed during the negotiation phase, and the particular code in use can be changed during the transfer phase, thus allowing the protocol to handle special files such as job output files, graphics files with embedded text, or symbolic files produced by a compiler for debugging purposes. Binary files can use byte sizes of any arbitrary size as agreed in advance.

   Error control is provided by the use of  data  checkpoints.   These

are inserted by the sender at suitable points, and may be matched to the characteristics of the file source or destination storage devices. The acknowledgement of a data mark implies that the data has been securely stored by the receiver. The use of a data window of unacknowledged data marks enables the sender to detect problems at the receiving end which will cause it to suspend the flow of data. On recovery (or in any appropriate circumstance), the receiver can ask the sender to resume the transfer starting from any mark after the last mark acknowledged. This facility also protects the transfer against loss of data within the network, and can even be used to resume an interrupted transfer in a separate session.

   Flow control is provided by allowing the receiver  to  request  the

sender to suspend the flow of data, and to tell it when to resume. This is primarily intended to cover device interruptions (eg mounting a magnetic tape). The use of these options is again subject to prior agreement during the initial negotiation phase, as with all the other attributes.

   The mechanics of  the  data  transfer  is  left  to  the  transport

mechanism. The protocol is defined so as to make minimal assumptions about the transport service. These are: the transport service will provide a synchronised sequential bytestream between the two sides with an acceptably low rate of error, and that if an unrecoverable error does occur, there exists some way for the transport service to notify the application process. Recovery would then be handled by the error control mechanism described above.

                                   4

2. Assessment of the NI FTP.

The design of the NI FTP was governed by four basic objectives:

   (i) The protocol should be independent of the communication medium.
   (ii) It should be flexible enough to satisfy a diverse  variety  of
   applications.
   (iii) It should be able to interface easily  to  a  wide  range  of
   operating systems.
   (iv) It should allow "escape routes" such that special features  of
   a particular operating system can be exploited where necessary.

The following features of the protocol were designed to meet these objectives:

   (i) The minimal requirements necessary  from  a  transport  service
   were  identified  and  adhered  to, along with the recognition that
   unrecoverable errors (at transport level) may occur.
   (ii) The definition of the file is in terms of  a  conceptual  file
   store.   No  restrictions  were  placed on the mapping of this file
   store  to  the  local  file  store,  either   in   the   attributes
   specification or in the definition of the negotiation process.  The
   inclusion of option sets and relational operators in the  attribute
   specification  allows  extensions  to  be  easily incorporated into
   existing implementations and into the protocol itself.  A number of
   parameters  provide  the  required  "escape routes" for areas where
   operating system dependent peculiarities are anticipated.  
   (iii) Complete transparency for naming files and for data  transfer
   is possible.
   (iv) The "records" of data transfer used within the protocol enable
   mixing  of  control and data within a single connection.  They need
   have no relation to the record structure (if any) used  within  the
   file, unless the user so desires.  The only restriction is that the
   communication medium should deliver eight  bit  bytes  of  data  in
   sequence.
   (v) The formats of control commands and attributes are standardised
   in  a machine-oriented form.  The action of the protocol is defined
   as a single file transfer transaction.  Hence the dominant need for
   flexible  command  formats occurs in the negotiation phase, and the
   level 0 commands are very loosely structured  to  allow  indefinite
   extension.   Only a very small number of commands must be exchanged
   during the data transfer; for this reason, a more  rigid  structure
   was adopted for level 1 commands to ease processing overhead.  
/data/webs/external/dokuwiki/data/pages/rfc/ien/ien99.txt · Last modified: 2001/06/25 18:51 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki