Vous êtes sur la page 1sur 12

NATIONAL INSTITUTE OF TECHNOLOGY KARNATAKA Department of Computer Science and Engineering

Advance Topics in Network and Distributed Systems

Assignment = 1 Submitted To: Mrs. Saumya Hegde

Submitted By:

M C Harshavardhana (09CO45) Jaim Jac Jones Mayak Mehta Adit Patel Rishabh M Gupta Class 3, Group 3 (09CO33) (09CO49) (09CO05) (09CO79)

File Transfer Protocol (FTP) is a standard network protocol used to transfer files from one host to another host over a TCP-based network, such as the Internet. FTP is built on a client-server architecture and uses separate control and data connections between the client and the server. FTP users may authenticate themselves using a clear-text signin protocol, normally in the form of a username and password, but can connect anonymously if the server is configured to allow it. For secure transmission that hides (encrypts) the username and password, and encrypts the content, FTP is often secured with SSL/TLS ("FTPS"). SSH File Transfer Protocol ("SFTP") is sometimes also used instead.

Figure: File Transfer Protocol (FTP) FTP is a standard protocol with STD Number 9. Its status is recommended. Copying files from one machine to another is one of the most frequently used operations. The data transfer between client and server can be in either direction. The client may send a file to the server machine. It may also request a file from this server. To access remote files, the user must identify himself to the server. At this point the server is responsible for authenticating the client before it allows the file transfer. From an FTP user's point of view, the link is connection-oriented. In other words, it is necessary to have both hosts up and running TCP/IP to establish a file transfer. FTP may run in active or passive mode, which determines how the data connection is established. In active mode, the client creates a TCP control connection to the server and sends the server the client's IP address and an arbitrary client port number, and then waits until the server initiates the data connection over TCP to that client IP address and client port number. In situations where the client is behind a firewall and unable to accept incoming TCP connections, passive mode may be used. In this mode, the client uses the control connection to send a PASV command to the server and then receives a server IP address and server port number from the

server, which the client then uses to open a data connection from an arbitrary client port to the server IP address and server port number received. Further changes were introduced to the passive mode at that time, updating it to extended passive mode.

While transferring data over the network, four data representations can be used:

ASCII mode: used for text. Data is converted, if needed, from the sending host's character representation to "8-bit ASCII" before transmission, and (again, if necessary) to the receiving host's character representation. As a consequence, this mode is inappropriate for files that contain data other than plain text. Image mode (commonly called Binary mode): the sending machine sends each file byte for byte, and the recipient stores the bytestream as it receives it. (Image mode support has been recommended for all implementations of FTP). EBCDIC mode: use for plain text between hosts using the EBCDIC character set. This mode is otherwise like ASCII mode. Local mode: Allows two computers with identical setups to send data in a proprietary format without the need to convert it to ASCII

For text files, different format control and record structure options are provided. These features were designed to facilitate files containing Telnet or ASA formatting. Active FTP In active mode FTP the client connects from a random unprivileged port (N > 1023) to the FTP server's command port, port 21. Then, the client starts listening to port N+1 and sends the FTP command PORT N+1 to the FTP server. The server will then connect back to the client's specified data port from its local data port, which is port 20. From the server-side firewall's standpoint, to support active mode FTP the following communication channels need to be opened:

FTP server's port 21 from anywhere (Client initiates connection) FTP server's port 21 to ports > 1023 (Server responds to client's control port) FTP server's port 20 to ports > 1023 (Server initiates data connection to client's data port) FTP server's port 20 from ports > 1023 (Client sends ACKs to server's data port)

When drawn out, the connection appears as follows:

In step 1, the client's command port contacts the server's command port and sends the command PORT 1027. The server then sends an ACK back to the client's command port in step 2. In step 3 the server initiates a connection on its local data port to the data port the client specified earlier. Finally, the client sends an ACK back as shown in step 4. The main problem with active mode FTP actually falls on the client side. The FTP client doesn't make the actual connection to the data port of the server--it simply tells the server what port it is listening on and the server connects back to the specified port on the client. From the client side firewall this appears to be an outside system initiating a connection to an internal client-something that is usually blocked. Passive FTP In order to resolve the issue of the server initiating the connection to the client a different method for FTP connections was developed. This was known as passive mode, or PASV, after the command used by the client to tell the server it is in passive mode. In passive mode FTP the client initiates both connections to the server, solving the problem of firewalls filtering the incoming data port connection to the client from the server. When opening an FTP connection, the client opens two random unprivileged ports locally (N > 1023 and N+1). The first port contacts the server on port 21, but instead of then issuing a PORT command and allowing the server to connect back to its data port, the client will issue the PASV command. The result of this is that the server then opens a random unprivileged port (P > 1023) and sends the

PORT P command back to the client. The client then initiates the connection from port N+1 to port P on the server to transfer data. From the server-side firewall's standpoint, to support passive mode FTP the following communication channels need to be opened:

FTP server's port 21 from anywhere (Client initiates connection) FTP server's port 21 to ports > 1023 (Server responds to client's control port) FTP server's ports > 1023 from anywhere (Client initiates data connection to random port specified by server) FTP server's ports > 1023 to remote ports > 1023 (Server sends ACKs (and data) to client's data port)

When drawn, a passive mode FTP connection looks like this:

In step 1, the client contacts the server on the command port and issues the PASV command. The server then replies in step 2 with PORT 2024, telling the client which port it is listening to for the data connection. In step 3 the client then initiates the data connection from its data port to the specified server data port. Finally, the server sends back an ACK in step 4 to the client's data port. While passive mode FTP solves many of the problems from the client side, it opens up a whole range of problems on the server side. The biggest issue is the need to allow any remote connection to high numbered ports on the server. Fortunately, many FTP daemons, including the popular WU-FTPD allow the administrator to specify a range of ports which the FTP server will use. The second issue involves supporting and troubleshooting clients which do (or do not) support passive mode. As an example, the command line FTP utility provided with Solaris does not support passive mode, necessitating a third-party FTP client, such as ncftp.

With the massive popularity of the World Wide Web, many people prefer to use their web browser as an FTP client. Most browsers only support passive mode when accessing ftp:// URLs. This can either be good or bad depending on what the servers and firewalls are configured to support. Data transfer can be done in any of three modes:

Stream mode: Data is sent as a continuous stream, relieving FTP from doing any processing. Rather, all processing is left up to TCP. No End-of-file indicator is needed, unless the data is divided into records. Block mode: FTP breaks the data into several blocks (block header, byte count, and data field) and then passes it on to TCP. Compressed mode: Data is compressed using a single algorithm (usually run-length encoding).


ABOR - abort a file transfer CWD - change working directory DELE - delete a remote file LIST - list remote files MDTM - return the modification time of a file MKD - make a remote directory NLST - name list of remote directory PASS - send password PASV - enter passive mode PORT - open a data port PWD - print working directory QUIT - terminate the connection RETR - retrieve a remote file RMD - remove a remote directory RNFR - rename from RNTO - rename to SITE - site-specific commands SIZE - return the size of a file STOR - store a file on the remote host TYPE - set transfer type USER - send username

FTP Model
FTP uses TCP as transport protocol to provide reliable end-to-end connections. Two connections are used: the first is the control connection and the second is the data connection that is managing the data transfer. The user who initiates the control connection assumes the client function, while the server function is provided by the remote host. On both sides of the link the FTP application is built with a protocol interpreter (PI) and a data transfer process (DTP). On the client side of the link there exists also a user interface.

The user interface communicates with the protocol interpreter, which is in charge of the control connection. The protocol interpreter, besides its function of responding to the control protocol, has also to manage the data connection. During the file transfer, the data management is performed by the DTPs. The FTP Protocol Modes The FTP protocol is a complex protocol because it uses a control connection (the primary connection) and a data connection (the secondary connection). How the data connection is made depends on the FTP protocol mode. There are two FTP modes:

Normal or PORT or Active Mode Passive or PASV Mode

The Control connection The control connection is the communication path between the USER-PI and SERVER-PI for the exchange of commands and replies. This connection follows the Telnet Protocol. When an FTP client wants to exchange files with an FTP server, the FTP client must first set up the control connection. The client makes a TCP connection from a random unprivileged port N (N > 1023) to the FTP server's well known command port 21 (the IANA assigned port number). Schematically the information flow is as follows:

It is important to note that the protocol requirest the control connection to remain open while the data transfer is in progress. In other words, a data connection cannot exist without an open control connection. On the other hand, the data connection doesn't need to exist all of the time and there can be many data connections during the lifetime of a control connection. As a final note, it is the responsibility of the user to request the closing of the control connection when finished using the FTP service. However, it is the server who takes the action to close the control connection. The Data connection The data connection is the communication path between the USER-DTP and SERVER-DTP for the exchange of the real data, being directory lists and files. Depending on the choosen FTP mode, the data connection is initiated from the server (active mode) or the client (passive mode).

In active mode, the client sends a PORT command to the server. Basically this command tells the server to which host (IP address) and port number (unprivileged port > 1023) the server must connect back for the data connection. After accepting the Port command, the server will then establish the data connection from its local data port 20 (the IANA assigned port number) to the IP address and port number learned from the PORT command. In passive mode, the client sends a PASV command to the server. Basically this command asks the server to "listen" on a data port (which is not its default data port 20) and to wait for a connection rather than to initiate one. If the server supports the passive mode, it will send a reply to this command including the host (IP address) and port number (unprivileged port > 1023) this server is listening on. The client will then establish the data connection from a local random unprivileged port (> 1023) to the IP address and port number learned from the PASV reply. It is important to note that the data connection will only be established upon receipt of the reply to the Transfer Service commands such as LIST, RETR, STOR. So, the FTP mode must be selected by the client before sending the appropriate Transfer Service command. Also, those Transfer Service commands wil get more than one reply: first a 'Positive Preliminary Reply' indicating the data transfer may start and after ending the data transfer a 'Positive Completion Reply'. Schematically the information flow is as follows:

The TFTP protocol is a standard protocol with STD number 33. TCP/IP file transfer is a disk-todisk data transfer, as opposed to, for example, the VM SENDFILE command, a function that is considered in the TCP/IP world as a mailing function, where you send out the data to someone's mailbox (reader in the case of VM). TFTP is an extremely simple protocol to transfer files. It is implemented on the internet UDP layer (User Datagram Protocol) and lacks most of the features of FTP. The only thing it can do is read/write a file from/to a server. The real TFTP protocol is implemented using UDP. Since UDP is unreliable, it adds a huge amount of coding complexity (that is better to avoid for now). Your version of TFTP will be slight variation of the TFTP protocol implemented over a TCP connection which is guaranteed to be reliable. TFTP supports five types of packets: Opcode 1 2 3 4 5 Operation Read request (RR Write request (WRQ) Data (DATA) Acknowledgment (ACK) Error (ERRO

The client and server will communicate with each other by sending packets of data back and forth. The format of these packets is as follows:


Three modes of transfer are currently defined in RFC 1350: NetASCII US-ASCII as defined in USA Standard Code for Information Interchange with modifications specified in RFC 854 - Telnet Protocol Specification and extended to use the high order bit. That is, it is an 8-bit character set, unlike US-ASCII which is 7-bit. Octet Raw 8-bit bytes, also called binary. Mail This mode was originally defined in RFC 783 and was declared obsolete by RFC 1350. It allowed for sending mail to a user rather than transferring to a file. The mode used is indicated in the Request for Read/Write packet (RRQ/WRQ). The TFTP header of a packet contains the opcode associated with that packet.

Each packet begins with a 2-byte opcode. Filenames and error messages are specified in ASCII and terminated with a zero byte (EOS). Data is sent in blocks of 512 bytes or less. RRQ and WRQ packets (opcodes 1 and 2 respectively) have the format shown in Figure. The file name is a sequence of bytes in netascii terminated by a zero byte. The mode field contains the string "netascii", "octet", or "mail" (or any combination of upper and lower case, such as "NETASCII", NetAscii", etc.) in netascii indicating the three modes defined in the protocol. A host which receives netascii mode data must translate the data to its own format. Octet mode is used to transfer a file that is in the 8-bit format of the machine from which the file is being transferred. It is assumed that each type of machine has a single 8-bit format that is more common, and that that format is chosen. For example, on a DEC-20, a 36 bit machine, this is four 8-bit bytes to a word with four bits of breakage. If a host receives a octet file and then returns it, the returned file must be identical to the original. Mail mode uses the name of a mail recipient in place of a file and must begin with a WRQ. Otherwise it is identical to netascii mode. The mail recipient string should be of the form "username" or "username@hostname". If the second form is used, it allows the option of mail forwarding by a relay computer. The discussion above assumes that both the sender and recipient are operating in the same mode, but there is no reason that this has to be the case. For example, one might build a storage server. There is no reason that such a machine needs to translate netascii into its own form of text. Rather, the sender might send files in netascii, but the storage server might simply store them without translation in 8-bit format. Another such situation is a problem that currently exists on DEC-20 systems. Neither netascii nor octet accesses all the bits in a word. One might create a special mode for such a machine which read all the bits in a word, but in which the receiver stored the information in 8-bit format. When such a file is retrieved from the storage site, it must be restored to its original form to be useful, so the reverse mode must also be implemented. The

user site will have to remember some information to achieve this. In both of these examples, the request packets would specify octet mode to the foreign host, but the local host would be in some other mode. No such machine or application specific modes have been specified in TFTP, but one would be compatible with this specification.