INTERNET-DRAFT G. Chin Document: draft-chin-dnftp-00.txt F. Cantero Expires: November 2005 Instituto Tecnolgico de Costa Rica May 2005 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 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Chin, Cantero Expires - November 2005 [Page 1] DNFTP Distributed New File Transfer Protocol May 2005 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 2005 [Page 2] DNFTP Distributed New File Transfer Protocol May 2005 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 2005 [Page 3] DNFTP Distributed New File Transfer Protocol May 2005 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 2005 [Page 4] DNFTP Distributed New File Transfer Protocol May 2005 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 2005 [Page 5] DNFTP Distributed New File Transfer Protocol May 2005 ---------- ---------- ------------- |/------\| |/------\| |/---------\| || 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 2005 [Page 6] DNFTP Distributed New File Transfer Protocol May 2005 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 2005 [Page 7] DNFTP Distributed New File Transfer Protocol May 2005 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 2005 [Page 8] DNFTP Distributed New File Transfer Protocol May 2005 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 2005 [Page 9] DNFTP Distributed New File Transfer Protocol May 2005 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 2005 [Page 10] DNFTP Distributed New File Transfer Protocol May 2005 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 2005 [Page 11] DNFTP Distributed New File Transfer Protocol May 2005 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 2005 [Page 12] DNFTP Distributed New File Transfer Protocol May 2005 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 2005 [Page 13] DNFTP Distributed New File Transfer Protocol May 2005 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 2005 [Page 14] DNFTP Distributed New File Transfer Protocol May 2005 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 2005 [Page 15] DNFTP Distributed New File Transfer Protocol May 2005 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 2005 [Page 16] DNFTP Distributed New File Transfer Protocol May 2005 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 2005 [Page 17] DNFTP Distributed New File Transfer Protocol May 2005 - 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 2005 [Page 18] DNFTP Distributed New File Transfer Protocol May 2005 - 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 2005 [Page 19] DNFTP Distributed New File Transfer Protocol May 2005 2. Michael Afergan. Java Soluciones Instantßneas. 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 Tecnolgico de Costa Rica San Jos‰, Costa Rica Phone: 506 3744395 Email: gchinl@techinbiz.net Fernando Cantero Instituto Tecnolgico de Costa Rica San Jos‰, Costa Rica Phone: 506 3991283 Email: fcantero@ic-itcr.ac.cr Chin, Cantero Expires - November 2005 [Page 20]