Internet DRAFT - draft-chin-dnftp

draft-chin-dnftp





   INTERNET-DRAFT                                               G. Chin 
   Document: draft-chin-dnftp-01.txt                         F. Cantero 
   Expires: November 2006                                     Instituto 
                                                         Tecnologico de 
                                                             Costa Rica 
                                                               May 2006 
    
    
                  Distributed New File Transfer Protocol 
    
    
Status of this Memo 
    
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79. 
    
   This document is subject to the rights, licenses and restrictions 
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights. 
 
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that      
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt 
   The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html. 
    
   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    
   This Internet-Draft will expire on November 2006. 
    
   Copyright Notice 
    
      Copyright (C) The Internet Society (2006).  All Rights Reserved. 
 
 
Chin, Cantero          Expires - November 2006               [Page 1] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
    
    
Abstract 
    
   This document specifies DNFTP, a new proposal of a protocol to 
   replace the FTP.  The fundamental objective is to make it more 
   feature rich, keeping the existent one, to adapt new technologies 
   that have been developing in the last decade like distributed 
   computing, multimedia and concurrency. 
    
Conventions used in this document 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC-2119 [1]. 
    
Table of Contents 
    
   1. Introduction...................................................3 
   2. Discussion.....................................................3 
      2.1 Terminology................................................3 
      2.2 Models.....................................................5 
          2.3.1 The FTP Model........................................5 
          2.2.2 The DNFTP Model......................................5 
   3. DNFTP Main Components..........................................6 
      3.1 Console Functionality......................................6 
      3.2 Command Exchange Functionality.............................7 
      3.3 Data Transfer Functions....................................7 
      3.4 Data Representation and Storage............................7 
      3.5 Establishing Data Connections..............................7 
      3.6 Transmission Modes.........................................7 
      3.7 Error Recovery and Restart.................................8 
          3.7.1 File Transfer Cache..................................8 
          3.7.2 End File Add-on......................................8 
   4. File Transfer Functions........................................9 
      4.1 FTP Commands...............................................9 
          4.1.1 Access Control Commands..............................9 
          4.1.2 File Handling Commands..............................10 
          4.1.3 Transfer Parameter Commands.........................10 
   5. Commands and Byte Mappings....................................11 
   6. Commands Exchange Samples.....................................16 
   7. SLP Implementation............................................18 
      7.1 TCP Support...............................................18 
      7.2 UDP Support...............................................18 
   8. API...........................................................18 
   9. Future Work...................................................19 
   Security Considerations..........................................19 
   References.......................................................19 
   Author's Addresses...............................................20 
 
 
Chin, Cantero          Expires - November 2006               [Page 2] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
    
1. Introduction 
    
   The DNFTP maintains the original objectives of the FTP which are: 1) 
   to promote sharing of files (computer programs and/or data), 2) to 
   encourage indirect or implicit (via programs) use of remote 
   computers, 3) to shield a user from variations in file storage 
   systems among Hosts, and 4) to transfer data reliably and 
   efficiently.  Also with DNFTP a new main objective is introduced 
   which is to give more functionality to the FTP protocol keeping the 
   existent, and to adapt technologies that have been developing in the 
   last and current decade like distributed computing, multimedia and 
   concurrency into one more advanced and functionality rich solution. 
    
   The attempt in this specification is to satisfy the diverse needs of 
   users with a simple and easily implemented protocol design. 
    
   This document assumes knowledge of the following protocols described 
   in the ARPA Internet Protocol Handbook. 
    
      The Transmission Control Protocol 
      The TELNET Protocol 
      The File Transfer Protocol 
      The Service Location Protocol 
    
2. Discussion 
    
   In this section, the terminology the old FTP model and the DNFTP 
   model are discussed. The terms defined in this section are only those 
   that have special significance in FTP.  Some of the terminology is 
   very specific to the FTP model; some readers may wish to turn to the 
   section on the FTP model while reviewing the terminology. 
    
2.1 Terminology 
    
   The following terminology is used during this document and should be 
   well handled before continuing with the document.  Also the 
   terminologies section from the RFCs mentioned in the discussion 
   section should be studied as well.  Some of the definitions were 
   obtained from the isp.webopedia.com - The Glossary for Internet 
   Service Providers. 
    
   TCP: Abbreviation of Transmission Control Protocol, and pronounced as 
   separate letters. TCP is one of the main protocols in TCP/IP 
   networks.  TCP enables two hosts to establish a connection and 
   exchange streams of data. TCP guarantees delivery of data and also 
   guarantees that packets will be delivered in the same order in which 
   they were sent. 
     
 
 
Chin, Cantero          Expires - November 2006               [Page 3] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
   IP: Short for Internet Protocol. IP specifies the format of packets, 
   also called datagrams, and the addressing scheme. 
    
   TCP/IP: Short for Transmission Control Protocol/Internet Protocol, 
   the suite of communications protocols used to connect hosts on the 
   Internet. TCP/IP uses several protocols, the two main ones being TCP 
   and IP. TCP/IP is built into the UNIX operating system and is used by 
   the Internet, making it the de facto standard for transmitting data 
   over networks. Even network operating systems that have their own 
   protocols(such as Netware), which also support TCP/IP. 
    
   FTP: Short for File Transfer Protocol, the protocol for exchanging 
   files over the Internet. FTP works in the same way as HTTP for 
   transferring Web pages from a server to a user's browser and SMTP for 
   transferring electronic mail across the Internet, like these 
   technologies, FTP uses the Internet's TCP/IP protocols to enable data 
   transfer. 
    
   NFS: Abbreviation of Network File System, a client/server application 
   designed by Sun Microsystems that allows all network users to access 
   shared files stored on computers of different types. NFS provides 
   access to shared files through an interface called the Virtual File 
   System (VFS) that runs on top of TCP/IP. Users can manipulate shared 
   files as if they were stored locally on the user's own hard disk. 
    
   SLP: service location protocol. protocol used to define information 
   directories in internet. 
    
   SDK: Short for software development kit, a programming package that 
   enables a programmer to develop applications for a specific platform. 
   Typically an SDK includes one or more APIs, programming tools, and 
   documentation. 
    
   API: Abbreviation of application program interface, a set of 
   routines, protocols, and tools for building software applications. A 
   good API makes it easier to develop a program by providing all the 
   building blocks. A programmer puts the blocks together. 
    
   GUI: Acronym for graphical user interface. 
    
   MIRRORING: Mechanism to store data in a redundant to prevent failures 
   and data loss. 
    
   RAID: Short for Redundant Array of Independent (or Inexpensive) 
   Disks, a category of disk drives that employ two or more drives in 
   combination for fault tolerance and performance. RAID disk drives are 
   used frequently on servers but aren't generally necessary for 
   personal computers. 
    
 
 
Chin, Cantero          Expires - November 2006               [Page 4] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
   RFC: Short for Request for Comments, a series of notes about the 
   Internet, started in 1969 (when the Internet was the ARPANET). An 
   Internet Document can be submitted to the IETF by anyone, but the 
   IETF decides if the document becomes an RFC. Eventually, if it gains 
   enough interest, it may evolve into an Internet standard. 
    
   JAVA:  A high-level programming language developed by Sun 
   Microsystems. Java was originally called OAK, and was designed for 
   handheld devices and set-top boxes. Oak was unsuccessful so in 1995 
   Sun changed the name to Java and modified the language to take 
   advantage of the burgeoning World Wide Web. 
    
2.2 Models 
    
   The previous FTP model which is included in the FTP RFC 765 is shown 
   for comparison purposes.   
    
2.3.1 The FTP Model 
                                                                                      
                                               ------------- 
                                               |/---------\| 
                                               ||   User  ||    -------- 
                                               ||Interface|<--->| User | 
                                               |\----:----/|    -------- 
                     ----------                |     V     | 
                     |/------\|  FTP Commands  |/---------\| 
                     ||Server|<---------------->|   User  || 
                     ||  PI  ||   FTP Replies  ||    PI   || 
                     |\--:---/|                |\----:----/| 
                     |   V    |                |     V     | 
         --------    |/------\|      Data      |/---------\|    -------- 
         | File |<--->|Server|<---------------->|  User   |<--->| File | 
         |System|    || DTP  ||   Connection   ||   DTP   ||    |System| 
         --------    |\------/|                |\---------/|    -------- 
                     ----------                ------------- 
    
                     Server-FTP                   User-FTP 
    
    
   Notes:  
   1. The data connection can be used in any direction. 
   2. The data connection doesn't necessarily exist all the time. 
   PI = Protocol Interpreter. Sends and does interpretation of commands.  
   DTP = Data Transfer Process.  Sends and receives bytes of data from 
   files. 
    
2.2.2 The DNFTP Model 
    
             
 
 
Chin, Cantero          Expires - November 2006               [Page 5] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
            ----------   ----------            ------------- 
            |/------\|   |/------\|            |/---------\| 
            || SLP  ||   || SLP  ||            ||   User  ||    -------- 
            || DA/SA|<--->| DA/SA||            ||Interface|<--->| User | 
            |\--:---/|   |\--:---/|            |\----:----/|    -------- 
            |   V    |   |   V    |            |     V     | 
            |/------\|   |/------\|FTP Commands|/---------\| 
            ||Server|<--->|Server|<----------->||   User  || 
            ||  PI  ||   ||  PI  || FTP Replies||    PI   || 
            |\--:---/|   |\--:---/|            |\----:----/| 
            |   V    |   |   V    |            |     V     |     
            |/------\|   |/------\|    Data    | --------  |    -------- 
            ||Server <--->|Server|<------------>|  User   |<--->| File | 
            || DTP  ||   || DTP  || Connection ||   DTP   ||    |System| 
            |\------/|   |\------/|            |\---------/|    -------- 
            ----------   ----------            ------------- 
                |            | 
             --------     --------  
             | File |     | File | 
             |System|     |System| 
             --------     -------- 
    
           Server-DNFTP  Server-DNFTP            User-DNFTP 
                  Server Group 
                
   Notes: 
    
    
   1. The data connection can be used in any direction. 
   2. The data connection doesn't necessarily exist all the time. 
   3. Data connections can be opened from a client to any given server 
   once that the server its connected to instructs it do so by 
   specifying the new server address. 
   PI = Protocol Interpreter. Sends and does interpretation of commands.  
   In the DNFTP this is included as part of a Telnet emulation which 
   connects clients with servers and servers with servers. 
   DTP = Data Transfer Process.  Sends and receives bytes of data from 
   files. In the DNFTP this is known as the Data Transfer Class 
    
3. DNFTP Main Components 
    
   Several important aspects of the components that compose the DNFTP 
   are highlighted below. 
    
3.1 Console Functionality 
    
   There should exist a component that handles the input from users in 
   the client.  This is a console that accepts the commands supported by 
   the DNFTP, which are described below with their correct syntax. This 
 
 
Chin, Cantero          Expires - November 2006               [Page 6] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
   can also be replaced by a GUI which would interact with the 
   application. This is the direct communication's link from the user 
   input to the DNFTP PI. 
    
3.2 Command Exchange Functionality 
    
   There should be a component that handles the commands exchange from 
   the client to the server and vice versa this acts also as 
   intermediary for the initial console to data transfer invocations. 
   This is explained below in more detail in the establishing data 
   connections section. The TELNET connection is used for the 
   transference of commands, which describe the functions to be 
   performed, and the replies to these commands (see the Section on FTP 
   Replies).  Several commands are concerned with the transference of 
   data between Servers, this commands are explained below with their 
   byte code. This is the direct communication's link between the PI or 
   Telnet emulation  and the DTP. 
    
3.3 Data Transfer Functions 
    
   Files as in FTP are transferred only via the data connection. A 
   Telnet emulation is also used with a random available system TCP port 
   so multiple files can be sent at the same time.  A buffer size of 536 
   is recommended, given that this is the default MTU for IP (576, minus 
   the standard size of IP and TCP headers) 
    
3.4 Data Representation and Storage  
    
   There should be a component called FileSystem in the server and 
   client that handles the communication with the computer's operating 
   File System.  From this you can access the files located in the 
   current computer and specify the working directory of the current 
   application. This should include functions to work with the files 
   (create, delete, rename, exists, cd, etc). This is the 
   communication's link between the DTP and the client's OS. 
    
3.5 Establishing Data Connections 
    
   There is a component that handles an emulation of a Telnet, in the 
   server and client, creating a connection with a socket and keeping it 
   alive for the duration of the operations until the user closes the 
   client connection in the terminal with one of the available commands 
   to kill the client application, or physically disconnects from the 
   server. 
    
3.6 Transmission Modes 
    
   There is just one transmission mode and that is binary, text mode is 
   not supported because it's considered unnecessary at the present 
 
 
Chin, Cantero          Expires - November 2006               [Page 7] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
   time, every file can be transferred in binary and documents with only 
   text are almost non existent at the current time because almost all 
   of them include some format that can't be represented in a text only 
   transfer mode.  In the case of a text only file, due to the size of 
   this, is easily and quickly transferred with current networks speed. 
    
3.7 Error Recovery and Restart 
    
   An isAlive message should be sent from time to time to determine if 
   the connection is still available with the remote client or server.  
   Also there must be timeouts defined that will trigger a disconnect or 
   retry procedure killing all the sockets and thread transferences, if 
   a package is not received within a specified time frame.  If this 
   happens the connection is aborted and retried for a few times, if 
   this still fails the transfer is temporarily aborted, until resumed 
   by the client.  Also for an extra dynamic awareness of physical 
   problems or disconnections in the network, all exceptions regarding 
   sockets and their connections should be catch and necessary action 
   taken in the client and the server. 
    
   Two approaches are suggested here to restart or resume data upload or 
   download, storing the following information: 
   Information to store about each file taking 400 bytes at a maximum: 
   Size in bytes: 20 bytes 
   File name: 256 bytes 
   Date and time of creation: 8 bytes 
   Date and time of last modification: 8 bytes 
   The last 108 bytes could be empty space or used for additional 
   information. 
    
3.7.1 File Transfer Cache 
    
   Kept in a file database in the server or the client.  As soon as a 
   transfer is started, it stores as a new entry the following 
   information in  memory (with a default capacity of 20 entries at a 
   time and a maximum amount specified by the user) and in a physical 
   file at the location of the running application.  Once the file 
   transference is completed this entry is eliminated. 
   The advantage is that the cache being a file database could be loaded 
   easily and fast. The disadvantage is that the files can only be 
   resumed from the current application or client. 
 
3.7.2 End File Add-on 
 
   This implementation could be supported by storing at the end of each 
   file being copied the information specified above. 
   At the start of each DNFTP client, a cache could be loaded with the 
   above information so if a client tries to download a file and matches 
   an entry in this cache it resumes.  To determine the specific last 
 
 
Chin, Cantero          Expires - November 2006               [Page 8] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
   byte of the file that wants to be resumed the size of this file has 
   to be determined by obtaining the current file size minus the last 
   400 bytes and continue retrieving bytes from this point.  The 
   difference between this approach and the File Transfer Cache approach 
   is that in the End File Add-on the information of the file to resume 
   is stored in the file itself and the cache is populated at the start 
   by looking at this information from each file.   
    
   The advantage from this approach is that the files could be moved to 
   another client and their download resumed from almost anywhere. The 
   disadvantage is that the cache could take more time to fill up at 
   start up. 
 
    
4. File Transfer Functions 
    
   There are different type of commands used in DNFTP.  Most of them 
   provide the same functionality as the ones in the FTP, but some are 
   anew. 
 
4.1 FTP Commands 
    
   Below are the commands that DNFTP supports and that the user can call 
   from the client's terminal or console.  How to use them in the 
   client's terminal is shown in parentheses. 
    
4.1.1 Access Control Commands 
 
   The following commands specify access control. 
    
   ACCOUNT (ACCT) 
   Used to include new users. 
    
   CONNECT (CONNECT, OPEN) 
   Connects to a server, can accept as a parameter the server name or IP 
   address. 
    
   DISCONNECT (DISCONNECT, CLOSE) 
   Disconnects from the current server. 
    
   HELP (HELP) 
   Displays the list of available commands that the user can execute in 
   the client.  Accepts as parameter the name of a command and returns 
   the help of the specified command if available. 
       
   LOGOUT (QUIT, BYE) 
   Disconnects from the current server and quits the client application. 
    
   SERVER LIST (SRVLIST) 
 
 
Chin, Cantero          Expires - November 2006               [Page 9] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
   Displays the online servers connected to a SLP directory agent that 
   can be accessed by the current client. 
    
   USER NAME (USER) 
   Changes the current user logged in. 
 
4.1.2 File Handling Commands 
 
   The following commands are related to interaction with the File 
   System.   
       
   CHAGE REMOTE DIRECTORY (CD) 
   Changes the remote directory of the client's application.  Accepts a 
   path as parameter.  
    
   CHANGE LOCAL DIRECTORY (LCD) 
   Changes the local directory of the client application.  Accepts a 
   path as parameter. If no parameter is specified it displays the 
   actual directory. 
    
   DELETE (DELETE) 
   Deletes the remote file. 
    
   DIR (DIR, LS, NDIR) 
   Browses the server files. 
    
   MAKE DIRECTORY (MKDIR) 
   Creates a new directory in the server. 
    
   PRINT WORKING DIRECTORY (PWD) 
   Prints the current directory where the user stands in the server. 
    
   RENAME (RENAME) 
   Renames the remote file. 
 
4.1.3 Transfer Parameter Commands 
 
   The following commands are related to the transference of data. 
    
   GET (GET, RECV, NGET) 
   Gets a file located in one of the active servers. Accepts a parameter 
   that is the name of the file to obtain. 
    
   MIRRORING (MIRRORING) 
   Mirrors the current directory structure and file content to the 
   server. 
    
   MULTIPLE GET (MGET) 

 
 
Chin, Cantero          Expires - November 2006              [Page 10] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
   Downloads multiple files at the same time from the server.  It works 
   like the GET, but receives multiple file names as parameters. 
    
   MULTIPLE PUT (MPUT) 
   Uploads multiple files at the same time in the server.  It works like 
   the PUT, but receives multiple file names as parameters. 
    
   PUT (PUT, SEND, NPUT) 
   Puts a file in the server.  Accepts a parameters that is the name of 
   the file to upload. 
    
5. Commands and Byte Mappings 
    
   It's going to be used a messaging structure as similar as the one 
   proposed by FTP, so future implementations could apply this mapping 
   and merge it with the one with the old FTP.  The FTP commands go from 
   the 100 to the 500 while the DNFTP commands go from 600 to 700.   
   The following are the commands short name and their number or code 
   equivalent that is sent in two bytes (with the exception of the 
   Acknowledge which only uses 1 byte).  These are send as commands, 
   requests, or responses from clients to servers, servers to clients, 
   and servers to servers: 
    
     Message: ACK 
     Code: 1 
     Structure: 2 bytes for the code. 
     Description: Acknowledge message. 
     
     Message: DIR  
     Code:  602 
     Structure: 2 bytes for the code. 
     Description: Shows the content of the remote actual directory. 
    
     Message: FILE  
     Code: 603 
     Structure: 2 bytes for the code + 1 byte for the length + n bytes 
     of the name of the   file or directory. 
     Description: Name of a file or directory.  Response to the Dir. 
    
     Message: ENDDIR  
     Code: 604 
     Structure: 2 bytes for the code. 
     Description: Last file or directory listed.  End dir no more files. 
    
     Message: GET  
     Code: 605 
     Structure: 2 bytes for the code. 
     Description: Receives a remote file.  Used to download. 
    
 
 
Chin, Cantero          Expires - November 2006              [Page 11] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
     Message: FILEPART  
     Code: 606 
     Structure: 2 bytes for the code + 1 byte length + 536 bytes of the 
     file 
     Description: Part or piece of a file. Answer to the GET.  Used to 
     download. 
    
     Message: FILEEND  
     Code: 607 
     Structure: 2 bytes for the code. 
     Description: Last piece or package of the file. Download ends 
    
     Message: PUT  
     Code: 608 
     Structure: 2 bytes for the code. 
     Description: Sends a local file.  Used for upload. 
    
     Message: PUTFILE 
     Code: 609 
     Structure: 2 bytes for the code + 1 byte of length + 536 bytes of 
     the file. 
     Description: Part of a file, response to the PUT.  Used for upload. 
    
     Message: ENDPUTFILE  
     Code: 610 
     Structure: 2 bytes for the code. 
     Description: Last piece or package of the file.  Used when the 
     upload ends 
    
     Message: FILENOTFOUND  
     Code:  611 
     Structure: 2 bytes for the code. 
     Description: File not found. 
    
     Message: FILEFOUND  
     Code: 612 
     Structure: 2 bytes for the code. 
     Description: File found. 
    
     Message: PORT  Code: 613 
     Structure: 2 bytes for the code + 2 bytes of the port number. 
     Description: Port number for data transference.  Port # will be 
     retransmitted. 
    
     Message: FILENAME  
     Code: 614 
     Structure: Variant. 
     Description: Name of a file. 
    
 
 
Chin, Cantero          Expires - November 2006              [Page 12] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
     Message: FILESIZE  
     Code: 615 
     Structure: Variant. 
     Description: Size of the file. 
    
     Message: USER  
     Code: 616 
     Structure: 2 bytes for the code + 1 byte of length + n bytes of the 
     username. 
     Description: Authenticates a new user with the server. 
    
     Message: PASSWORD  
     Code: 617 
     Structure: 2 bytes for the code. 
     Description: Authenticates a new user with the server.  Used to 
     send the password. 
    
     Message: OKLOGIN  
     Code: 618 
     Structure: 2 bytes for the code. 
     Description: Authentication successful. Login was successful. 
    
     Message: NOLOGIN  
     Code: 619 
     Code: Structure: 2 bytes for the code. 
     Description: Authentication failed.  Login fails. 
    
     Message: RENAME  
     Code: 620 
     Structure: 2 bytes for the code + 1 byte length + n bytes name of 
     the file + n bytes name of the new file. 
     Description: Changes the name of a file renaming it. 
    
     Message: OKRENAME  
     Code: 621 
     Structure: 2 bytes for the code. 
     Description: Rename successful. 
    
     Message: NORENAME 
     Code: 622 
     Structure: 2 bytes for the code. 
     Description: Rename failed. 
    
     Message: DELETE  
     Code: 623 
     Structure: 2 bytes for the code. 
     Description: Erases a file. 
    
     Message: PWD  
 
 
Chin, Cantero          Expires - November 2006              [Page 13] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
     Code: 624 
     Structure: 2 bytes for the code. 
     Description: Prints the current remote directory. 
    
     Message: REQUESTPERMISION  
     Code: 625 
     Structure: 2 bytes for the code + 1 byte length + n bytes command 
     name.  
     Description: Requests permission to execute a command. 
    
     Message: GRANTED  
     Code: 626 
     Structure: 2 bytes for the code. 
     Description: Permission granted. 
    
     Message: DENIED    
     Code: 627 
     Structure: 2 bytes for the code. 
     Description: Permission denied. 
    
     Message: ACCOUNT  
     Code: 628 
     Structure: 2 bytes for the code + 1 bytes of length + n bytes of 
     the name of the user + 1 byte of length + n  bytes of the password. 
     Description: Adds a new user in the server. 
    
     Message: OKACCOUNT  
     Code: 629 
     Structure: 2 bytes for the code. 
     Description:  Command account successful. 
    
     Message: NOACCOUNT  
     Code: 630 
     Structure: 2 bytes for the code. 
     Description: Command account failed. 
    
     Message: HASFILE  
     Code: 631 
     Structure: 2 bytes for the code + 1 byte length +  n bytes name of 
     the file. 
     Description: Asks if another server has the file. 
    
     Message: FILEFOUNDINOTHERSERVER  
     Code: 632 
     Structure: 2 bytes for the code. 
     Description: File found in the remote location. 
    
     Message: DISCONNECT  
     Code: 633 
 
 
Chin, Cantero          Expires - November 2006              [Page 14] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
     Structure: 2 bytes for the code. 
     Description: Closes the DNFP session.  Disconnects from the server. 
    
     Message: MIRRORING  
     Code: 634 
     Structure: 2 bytes for the code + 1 byte length + n bytes IP 
     Description: Makes a mirror copy of the contents of one server into 
     another. Can or cannot receive the info from the other server. 
    
     Message: OKMIRRORING  
     Code: 635 
     Structure: 2 bytes for the code. 
     Description: Mirroring command was successful. 
    
     Message: NOMIRRORING  
     Code: 636 
     Structure: 2 bytes for the code. 
     Description: Mirroring command was unsuccessful. 
    
     Message: CD  
     Code: 637 
     Structure: 2 bytes for the code + 1 byte length  + n bytes name of 
     the directory. 
     Description: Changes the remote actual directory. 
    
     Message: OKCD  
     Code: 638 
     Structure: 2 bytes for the code. 
     Description: CD command was successful. 
    
     Message: NOCD    
     Code: 639 
     Structure: 2 bytes for the code. 
     Description: CD command was unsuccessful. 
    
     Message: MKDIR  
     Code: 640 
     Structure: 2 bytes for the code + 1 byte length  + n bytes name of 
     directory. 
     Description: Creates a new remote directory. 
    
     Message: OKMKDIR  
     Code: 641 
     Structure: 2 bytes for the code. 
     Description: Command Mkdir successful. 
    
     Message: NOMKDIR  
     Code: 642 
     Structure: 2 bytes for the code. 
 
 
Chin, Cantero          Expires - November 2006              [Page 15] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
     Description: Command Mkdir unsuccessful. 
    
     Message: MESSAGE  
     Code: 643 
     Structure: 2 bytes for the code + 1 byte length + n bytes message. 
     Description: Text message from the server to the client. 
    
     Message: ISALIVE  
     Code: 644 
     Structure: 2 bytes for the code. 
     Description: Tests if the server or client is online. 
    
     Message: SERVLIST  
     Code: 645 
     Structure: 2 bytes for the code. 
     Description: Lists the IP addresses of the DNFTP servers. 
    
     Message: OKSERVLIST  
     Code: 646 
     Structure: 2 bytes for the code. 
     Description: Servlist command was successful. 
    
     Message: NOSERVLIST  
     Code: 647 
     Structure: 2 bytes for the code. 
     Description: Servlist command was unsuccessful. 
    
     Message: IP  
     Code: 648 
     Structure: 2 bytes for the code + 1 byte length + n bytes IP. 
     Description: IP address of a DNFTP server. 
    
     Message: ENDIP  
     Code: 649 
     Structure: 2 bytes for the code.  
     Description:  Final list of IP addresses of the DNFTP servers. 
 
6. Commands Exchange Samples 
 
   Below are examples of how should the commands and file pieces be 
   sent: 
    
   Send command example: 
   first command byte -> 
   <- ACK 
   second command byte -> 
   <- ACK 
    
   Send file example: 
 
 
Chin, Cantero          Expires - November 2006              [Page 16] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
   package piece 1 -> 
   <- ACK 
   package piece 2 -> 
   <- ACK 
   package piece n -> 
   <- ACK 
    
   Here is also included the sequence of commands necessary for a 
   download, upload and file navigation. The rest of the commands use a 
   similar structure. 
    
   File download (nget): 
    
      - Usage method: nget "filename" 
      - Example: >nget "file3.doc" 
    
   File found: 
      - GETFILE (606) 
      - ACK (1) 
      - FILE (603) 
      - ACK (1) 
      - Data (n times): a descriptor is sent with the package size. 
      - ACK (n times) (1) 
      - ENDGETFILE (607) 
      - ACK (1) 
    
   File not found: 
      - GETFILE (606) 
      - ACK (1) 
      - FILE (603) 
      - ACK (1) 
      - NOTFOUND (611)  
      - ACK(1) 
    
   File upload (nput): 
      - PUTFILE (609) 
      - ACK (1) 
      - FILE (603) 
      - ACK (1) 
      - Data, ACK (n times) (1) 
      - ENDPUTFILE (610) 
      - ACK (1) 
    
      - Usage: nput "filename" 
      - Example: >nput "file3.doc" 
    
   Navigate to see available files (ndir): 
      - DIR (602) 
      - ACK (1) 
 
 
Chin, Cantero          Expires - November 2006              [Page 17] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
      - Data, ACK (n times) (1) 
      - ENDDIR (604) 
      - ACK (1) 
    
      - Usage method: dir 
      - Example: >dir 
 
7. SLP Implementation 
    
   The DNFTP server should include a component to handle SLP support 
   this will allow dynamic discovery and update of DNFTP service 
   provider servers..   
   As stated in the design diagram, each server has the possibility to 
   start a SLP Directory Agent.  In this directory agent, other DNFTP 
   servers can be registered to allow multiple servers to be available 
   for the clients in a transparent way. 
   There should be support for TCP and UDP in the SLP implementation. 
   Each DNFTP server acts as a server agent. 
    
7.1 TCP Support 
    
   This is useful for any TCP connection local, wide or over the 
   Internet.  A central SLP server (or directory agent) exists that 
   receives connections from other DNFTP servers that act as Server 
   agents, or user agents. 
    
7.2 UDP Support 
   This is useful for LANs, allows auto discovery of DNFTP servers.  
   Each server can act as a directory agent.  Multicast is used to 
   advise a group of the specific new service availability. 
    
8. API 
    
   The API is available to provide communication with other 
   applications; it enables the direct implementation of the DNFTP 
   client and DNFTP server functionality without the need to rewrite the 
   code. 
    
   The API should be composed of 2 main components: 
     - DNFTPClientAPI: Available to create an instance of a client.  
        Can specify if a terminal should be visible or not.  Can invoke 
        any command a normal client could use like the ones described in 
        the DNFTP commands section.  This API must provide all the 
        required methods to directly sent the above commands specified 
        to the server.  The return types or information must be data 
        structures that can easily be handled and native of the 
        programming language. An option to show the messages to the 
        terminal or not should be enabled. 

 
 
Chin, Cantero          Expires - November 2006              [Page 18] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
     - DNFTPServerAPI: Available to create an instance of the server.  
        Listens to requests from the client or other servers.  Can start 
        the different types of DNFTP SLP directory agent. 
    
    
9. Future Work 
    
   The following is functionality that could be provided in the future 
   and will improve the DNFTP. 
     - Adapt it to interact directly with old clients and servers from 
        the original FTP. 
     - A TFTP support by using part of the UDP transfer engine provided 
        in the DNFTP UDP SLP API. 
     - Compression support 
     - Encryption for commands and data transfer. 
     - More support for SLP to allow the registration of other related 
        services. 
     - SLP Directory Agent redundancy for extra security when one 
        fails. 
     - Increase the fault tolerance and data security by implementing 
        RAID capability based on a mirroring enhancement. 
     - A network traffic analysis would be recommended to verify that 
        the bandwidth used is not causing a great weight for the network 
        at the time of the transfers. 
     - Operations of wait and sleep could be implemented to save 
        processor cycles in the both the client and the server. 
     - Additional security mechanisms could be implemented for the 
        authentication between the servers and file access protection by 
        defining SLP scopes to determine who can see what. 
     - Backup mechanisms for the data could be further enhanced by 
        providing RAID options for data duplicity in case a server 
        fails. 
     - A URL standard could be used in the future for the paths 
        specified within the console of the DNFTP client. 
    
Security Considerations 
    
   The document doesn't contain or explains security considerations 
   regarding the proposed protocol, this should be included in future 
   updates or are open to the readers and implementers. 
    
    
References 
                     
    
   1. Postel J. RFC 765 - File Transfer Protocol specification.  
   http://www.faqs.org/rfcs/rfc765.html. June 1980 
    

 
 
Chin, Cantero          Expires - November 2006              [Page 19] 
             DNFTP Distributed New File Transfer Protocol     May 2006 
 
 
   2. Michael Afergan. Java Soluciones Instantaneas. Prentice Hall. 
   1997. 
    
   3. Veizades J., Guttman E. RFC 854 – Service Location Protocol.  
   http://www.faqs.org/rfcs/rfc2165.html. June 1997. 
    
   4. Postel J., Reynolds J. RFC 854 – Telnet Protocol Specification. 
   http://www.faqs.org/rfcs/rfc854.html. May 1983. 
    
   5. S. Shepler; B. Callaghan. RFC 3010 - NFS version 4 Protocol 
   http://www.faqs.org/rfcs/rfc3010.html.  December 2000. 
    
   6. Comer, Douglas E. Internetworking with TCP/IP Vol I: Principles, 
   Protocols and Architecture. Fourth Edition, Prentice-Hall, USA, 2000. 
    
   7. Masinter L, Berners-Lee T. RFC 1738 – Uniform Resource Locators 
   (URL) http://www.faqs.org/rfcs/rfc1738.html. December 1994. 
    
 
Author's Addresses 
    
   Guillermo Chin 
   Instituto Tecnologico de Costa Rica 
   San Jose, Costa Rica 
   Phone: 506 3744395 
   Email: gchinl@techinbiz.net 
    
   Fernando Cantero 
   Instituto Tecnologico de Costa Rica 
   San Jose, Costa Rica 
   Phone: 506 3991283 
   Email: fcantero@ic-itcr.ac.cr 
     
















 
 
Chin, Cantero          Expires - November 2006              [Page 20]