Transfer Information Exchange
In the current world of information exchange, one needs a secured and fast data transfer without loss of information through the internet . FTP ,file transfer protocol is used to get the information from other computer through internet and also it can send its data to the other systems through internet .befor getting the data one has to be authenticated . some of the common uses of FTP are getting the software's from the other systems. some of the files may be too large to get that's why we use some compressing softwares like winzip, pkzip, binhex. This project implements the idea of an FTP Client which connects to the server on a particular port, makes requests and utilizes the services from the server.
EXISITING SYSTEM:
The existing techniques to transfer data include the Windows built-in features and also the HTTP. Eventhough Windows provides good transfer capabilities, but only on intranet rather than data transfer across the Internet because it uses a protocol, which is not supported on Internet. On the other hand HTTP protocol is considered to be vary ineffective because it is considered to be a stateless protocol. Due to this reason it turns out to be a resource consuming technique. It is also insecure, as it doesn't need any user authentication before sharing of data.
PROPOSED SYSTEM:
As a solution to this problem J. Postel and J. Reynolds proposed RFC 959 to Network Working Group on October 1985 and later FTP has been famous as a common mechanism to transfer files across Internet.
The advantages of FTP are
- We can share the files across the internet
2 To encourage indirect or implicit (via programs) use of remote computers.
3 To transfer data reliably and efficiently. FTP, though usable directly by users at terminals, but mainly used by programs.
SRS (Software Requirement Specification)
THE FTP MODEL
1. The data connection may be used in both directions.
2. The data connection need not to exist all the time.
3. Server-DTP
The data transfer process, in its normal "active" state, establishes the data connection with the "listening" data port. It arranges parameters for transfer and storage, and transfers data on command from its PI. The DTP can be placed in a "passive" state to listen for, rather than initiate the connection on the data port.
4. Server-FTP process
It is a process or set of processes which perform the function of file transfer in cooperation with a user-FTP process and, possibly, another server. The functions consist of a protocol interpreter (PI) and a data transfer process (DTP).
5. Server-PI
The server protocol interpreter "listens" on Port L for a connection from a user-PI and establishes a control communication connection. It receives standard FTP commands from the user-PI, sends replies, and manages the server-DTP.
6. User-DTP
The data transfer process "listens" on the data port for a connection from a server-FTP process. If two servers are transferring data between them, the user-DTP is inactive state.
7. User-FTP process
A set of functions including a protocol interpreter, a data transfer process and a user interface which together perform the function of file transfer in cooperation with one or more server-FTP processes. The user interface allows a local language to be used in the command-reply dialogue with the user.
8. User-PI
The user protocol interpreter initiates the control connection from its port U to the server-FTP process, initiates FTP commands, and governs the user-DTP if that particular process is part of the file transfer.
An FTP server basically serves as a file repository, which the client can query, place files on it and can also download files from it.
For this purpose the client should have the prior information like IP address of the server and the port on which the server is listening for requests. When a particular client attempts to connect to the server, it creates a separate process to handle the client. This process is same for every incoming client. This helps the server to serve multiple clients at atime. After a separate process is started, the client supplies the authentication scheme. Then the server welcomes the client by sending it a message representing that the initial hand shaking has been successful. If the authentication scheme has failed at the server then the server returns the error code after which the client is simply disconnected.
After successfully getting a client connection, the server proceeds to setup the user directory, which contains the contents such as querying the contents, storing file or retrieving files. The server also provides appropriate privileges & security to the client directory also called user directory.
ACCESS CONTROL COMMANDS
The client(command codes are shown in parentheses) is authenticated and authorized by the given commands and they also specify access control identifiers.
USER NAME (USER)
After the control connections are made the user sends or transmits the first command which the server needs for accessing to its file system, known as user identification.
USER <SP> <username> <CRLF>
PASSWORD (PASS)
Password needs to sensitive a there not only provide security but also authenticate the user and provide access control to some sites and passwords are masked or suppressed.
PASS <SP> <password> <CRLF>
CHANGE WORKING DIRECTORY (CWD)
The command which is used by the user for working with a different directory or retrieval without changing his login or accounting information is known as change working directory(CWD).a directory or other system dependent file group designator is specified by a pathname called argument.
CWD <SP> <pathname> <CRLF>
CHANGE TO PARENT DIRECTORY (CDUP)
A command is used to simplify the implementation of programs for transferring directory trees having different syntaxes for naming the parent directory. It is a special case of CWD.
CDUP <CRLF>
REINITIALIZE (REIN)
It is an interesting part of the process as it allows any transfers in progress but terminates a USER, flushing account information and all I/O.
REIN <CRLF>
LOGOUT (QUIT)
Once this command is send it ends communication between the server and the user and server will not close till the results are received .
QUIT <CRLF>
TRANSFER PARAMETER COMMANDS
These parameters have default values, and the commands specifying data transfer parameters are required only if the default parameter values has to be changed. The default value is nothing but the last specified value, or if no value has been specified, the standard default value is as stated here. This implies that the server must "remember" the applicable default values.
DATA PORT (PORT)
The argument is a HOST-PORT specification for the data port which has to be used in data connection. There are defaults for both the user and server data ports, and under normal situations this command and its reply are not needed. For this particular command, the argument is the concatenation of a 32-bit Internet host address and a 16-bit TCP port address. This address information is devided into 8-bit fields and the value of each field is transmitted as a decimal number (in character string representation). Commas separates the fields. A port command would be:
Ex: (Host Name is 100.100.100.1 and the port of Data Connection is 1000 ) PORT 100,100,100,1,3,232
PORT <SP> <host-port> <CRLF>
PASSIVE (PASV)
This command requests the server-DTP to "listen" on a data port and to wait for a connection rather than initiate one upon receipt of a transfer command.
PASV <CRLF>
REPRESENTATION TYPE (TYPE)
This command specifies how to initiate Data Transfer (weather in Text or Binary)
Ex: TYPE I or TYPE A
TYPE <SP> <type-code> <CRLF>
FTP SERVICE COMMANDS
The FTP service commands define the file transfer or the file system function requested by the user. there should be a confirmation between the language conventions of the control connection and the server which is done by the syntax of pathnames. This pathnames are normally argument of an FTP service command. when this FTP command transfer the date it is sent over the data connection this not always possible specially for certain informative replies.this can be in any order .except in few cases such as "rename from" command must be followed by a "rename to" command and the restart command must be followed by the interrupted service command (e.g., STOR or RETR).
The given commands specify FTP service requests:
RETRIEVE (RETR)
This command causes the server-DTP to transfer a copy of the file, specified in the pathname, to the client at the other end of the data connection. The status and contents of the file at the server site shall be unaffected i.e. to get a File from Server to Client.
RETR <SP> <pathname> <CRLF>
STORE (STOR)
STORE
This command causes the server-DTP to accept the data transferred via the data connection and to store the data as a file at the server site. If the file specified in the pathname exists at the server site, then its contents shall be replaced by the data being transferred. A new file is created at the server site if the file specified in the pathname does not exist.
STOR <SP> <pathname> <CRLF>
STORE UNIQUE (STOU)
This command behaves like STOR except that the resultant file is to be created in the current directory under a name unique to that directory. The 250 Transfer Started responses must include the name generated.
STOU <CRLF>
APPEND (APPE)
This command causes the server-DTP to accept the data transferred via the data connection and to store the data in a file at the server site. If the file specified in the pathname exists at the server site, then the data should be appended to that file, otherwise the specified file in the pathname shall be created at the server site.
APPE <SP> <pathname> <CRLF>
RENAME FROM (RNFR)
This command defines the old pathname of the file, which is to be renamed and must be immediately followed by a "rename to" command defining the new file pathname.
RNFR <SP> <pathname> <CRLF>
RENAME TO (RNTO)
Rename command specifies the new pathname of the file specified in the immediately preceding "rename from" command. Together the two commands cause a file to be renamed.
RNTO <SP> <pathname> <CRLF>
ABORT (ABOR)
This command tells the server to abort the previous FTP service command and any associated transfer of data. No action is to be taken if the previous command has been completed (including data transfer). The control connection is not to be closed by the server, but the data connection must be closed.
ABOR <CRLF>
DELETE (DELE)
This command causes the file specified in the pathname to be deleted at the server site. If an extra level of protection is desired (such as the query, "Do you really wish to delete?"), it should be provided by the user-FTP process.
DELE <SP> <pathname> <CRLF>
REMOVE DIRECTORY (RMD)
This command causes the directory specified in the pathname to be removed as a directory (if the pathname is absolute) or as a subdirectory of the current working directory (if the pathname is relative).
RMD <SP> <pathname> <CRLF>
MAKE DIRECTORY (MKD)
This command causes the directory specified in the pathname to be created as a directory (if the pathname is absolute) or as a subdirectory of the current working directory (if the pathname is relative).
MKD <SP> <pathname> <CRLF>
PRINT WORKING DIRECTORY (PWD)
This command causes the name of the current working directory to be returned in the reply.
PWD <CRLF>
LIST (LIST)
The list command sends a list from the server to the passive DTP. If the pathname specifies a directory or other group of files, the server should transfer a list of files in the specified directory. If the pathname specifies a file then the server should send current information on the file. A null argument implies the user's current working or default directory.
LIST [<SP> <pathname>] <CRLF>
NAME LIST (NLST)
NameList command causes a directory listing to be sent from server to user site. The pathname should specify a directory or other system-specific file group descriptor, a null argument implies the current directory. The server will return a stream of names of files and no other information.
NLST [<SP> <pathname>] <CRLF>
SYSTEM (SYST)
This command is used to find out the type of operating system operating at the server .
SYST <CRLF>
STATUS (STAT)
This command shall cause a status response to be sent over the control connection in the form of the reply.
STAT [<SP> <pathname>] <CRLF>
HELP (HELP)
This command allows the server to send helpful information about its implementation status over the control connection to the user.
HELP [<SP> <string>] <CRLF>
NOOP (NOOP)
This command does not influence any parameters or previously entered commands. It doesn't do nothing other than that the server sends an OK reply.
NOOP <CRLF>
Security:
FTP needs mechanism for authentication, authorizing connections message integrity and confidentiality which are part of network security. First authentication is developed between client and processor for secured data transfer.
FTP authorization is done with with a password, passed on the network to the PASS command. The possessor of this password command is presumed to be authorized to transfer files on user named in the USER command.
An FTP security interaction starts with a client telling the server which security mechanism it wants to use normally with the AUTH command. Its up to the server to accept or reject this mechanism. Password to be interpreted by the PASS command is encrypted with token or some thing for secure data transfer.
If the server needs additional security information, then the client and server will enter into a security data exchange. The client will send an ADAT command which contains the first block of security data. server replies if it needs additional data or when there is an error which contains client to interpret. If extra data is required, the client will again send another ADAT command containing the next block of data, and await for the server's reply. This exchange processes can continue as many times as required. Once this exchange completes, the client and server have established a Security association. this process may include authentication ,integrity, confidentiality.
If we have message integrity protector, then we can prevent an attacker from deleting and inserting commands.
Policy is not specified by this document. In particular, client and server implementations may choose to implement given restrictions on what operations can be performed depending on the security association, which exists. No particular set of functionality is required, except as dependencies which is described in the next section. This means that none of authentication, integrity, or confidentiality is required of an implementation, although a mechanism which does none of these is not of much use.
BIBLIOGRAPHY
RFC's (Request For Comments) on FTP
Bhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823),
MIT-Project MAC, 16 April 1971.
Harslem, Eric, and John Heafner, "Comments on RFC 114 (A File
Transfer Protocol)", RFC 141 (NIC 6726), RAND, 29 April 1971.
Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172
(NIC 6794), MIT-Project MAC, 23 June 1971.
Braden, Bob, "Comments on DTP and FTP Proposals", RFC 238 (NIC
7663), UCLA/CCN, 29 September 1971.
Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 265
(NIC 7813), MIT-Project MAC, 17 November 1971.
McKenzie, Alex, "A Suggested Addition to File Transfer Protocol",
RFC 281 (NIC 8163), BBN, 8 December 1971.
Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File
Transfer Protocol", RFC 294 (NIC 8304), MIT-Project MAC,
25 January 1972.
Bhushan, Abhay, "The File Transfer Protocol", RFC 354 (NIC 10596),
MIT-Project MAC, 8 July 1972.
Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC 354)",
RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972.
Hicks, Greg, "User FTP Documentation", RFC 412 (NIC 12404), Utah,
27 November 1972.
We provide a professional essay writing service that thousands of our customers use as an effective way of improving their grades, improving their research and saving them lots of time.
