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]
