FTP Client Application
Final Report
CSC 8560
Brian Jorgage
4/27/2004
FTP Client Application Report
Brian Jorgage
I. Introduction
This report summarizes the results of the semester-long project for the Networking
Systems class CSC 8560. My basic approach was to install an FTP server locally on my
development machine and then based on the RFC 959 (the FTP specification) to build an
FTP client that mimics the behavior of popular FTP clients.
II. Design Issues
The application was built using Visual Basic 6.0 and it makes use of the Winsock
network control. All socket connections were handled by the Winsock control. Major
issues involved in the project were synchronization between client and server processes
and the need to understand that Winsock is modeled after the TCP state machine.
III. Login Process
The Login process is accomplished via a handshaking protocol between client and server.
Once an initial connection is made, the client sends a “USER <userid>” command to the
server. The server responds to this with a 331 code to which the client must respond with
a “PASS <password>” command. Initially these were implemented as command buttons
but later on the synchronization logic was coordinated.
IV. FTP Sockets
The RFC specifies one control connection and one data connection. The control
connection is used to send short text command messages (e.g. USER, PASS) and the data
connection is used to transfer file content to and from the server.
The initiation of the control connection is specified by the PORT command which sends
client IP address and socket number to the server which then initiates the control
connection on that socket. The format is “PORT h1, h2, h3, h4, p1, p2”. The parameters
h1 through h4 specify the four parts of the IP address and the p1, p2 parameters specify
the port number in mod 256 arithmetic (same format as IP address). For example port
number 4440 would be represented as p1=17, p2=88 since 17 * 256 + 88 = 4440. I was
not able to get this aspect of the RFC working. The socket remained in a listening state
but the connection request never arrived from the server. I was unable to determine why
this was occurring. Fortunately the RFC specifies an alternate method of establishing the
control connection via the PASV (Passive) command. In this case the client sends a
“PASV” command with no parameters to the server and the server responds with its IP
address and an available port number. The client can then initiate and establish the
connection. This is essentially the reverse of the PORT command. This method worked
and was the one that was used throughout the development process.
V. FTP Get, Put and Dir
The FTP Get command is implemented as a “RETR <filename>”. The RFC specifies
that the file transfer is not complete until a 226 code is received from the server. The
FTP Put command is implemented as a “STOR <filename>” command. The FTP Dir
command is implemented as a “LIST” command.
All three of these commands transfer data on the data connection between the client and
the server. They all occur after the data connection has been established via the PORT or
PASV command. Since my implementation used the PASV command the server
responds to this with a 227 code. When the client receives a 227 I implemented a branch
based on whether the desired operation is DIR, GET or PUT. In the case of DIR and
GET the server transfers data to the client. In the case of PUT the client transfers data to
the server. In the case of PUT the FTP client then parses the file and sends its contents
along the data connection.
VI. Text Mode and Binary Mode
Text files and binary files are handles differently in FTP. Text mode is specified by
sending a “TYPE A” command and binary mode is specified by sending a “TYPE I”
command. Text mode is the default in FTP and doesn’t need to be specified. Images and
executable files need to be transferred via Binary mode.
VII. Directory Navigation
The RFC specifies that server –side navigation be accomplished via the CWD (change
working directory) command followed by the desired directory. This was implemented
as a double-click event on the client-side listbox. I needed to implement logic to be able
to distinguish between files and directories in the listbox. If a directory was selected it
would generate a CWD command. If a file was selected it would initiate a RETR (FTP
Get). A move up to the parent directory is accomplished via the “CDUP” command.
This was implemented as a distinct command button. Client-side navigation was
accomplished by the use of the CommonDialog control.
VIII. Managing Connections
Managing the state of the data and control connections turned out to be an issue during
development. When the server completes the transfer of a file in response to a GET
command it sends a 226 code (transfer complete). The connection is not released until
this event occurs. This is detected by the SendComplete( ) event in the Winsock control.
Likewise when the client is sending a file it needs to close the connection when it
completes. It was found that if the client process exits before both sockets are closed the
application will hang. It was necessary to implement logic to avoid this. The FTP Client
checks the state of both lines before exiting and if one of them is still open it will send a
message box to the user.
IX. Raw FTP Commands
The Raw FTP commands that were synchronized were collected together under a
separate menu heading to allow for low-level testing. For example, a GET can be
simulated by selecting the PASV menu option and then on receipt of a 227 code from the
server (visible in the listbox) then the RETR menu can be selected. Text mode is the
“TYPE A” menu and Binary mode is the “TYPE I” menu. The PORT command is also
on the menu although as stated earlier it has not been fully implemented by this
application. Additional commands under this menu heading are USER, PASS, PASV
(Passive connection), LIST (directory listing), STOR, STOU (store unique), SYST
(system information), STAT (status information), NOOP (no operation), HELP, REIN
(Reinitialize).
X. Remaining Issues
Additional issues encountered during the project included the fact that the Cerberus FTP
server seems to send raw file data in 8K chunks. Each chunk would generate a
DataArrival event on the Winsock data connection. As each chunk arrived I would
display a message box to the user. Eventually I did away with the message boxes since
they were becoming a nuisance. However this introduced a problem because the data
connection was being closed by the server before all the file data had been received by
the client. This was fixed by putting in logic to check for the size of the data chunk. If
the data chunk was 0 bytes then a warning is sent to the user but no action is taken.
Apparently during transmission some chunks are 0 bytes for whatever reason but this
does not signify the end of transmission.
Other features to add in the future could be various filesystem commands – Abort,
Delete, Mkdir, Rename
XI. Demo
The demo consists of an explanation of the menu options followed by a GET of a text file
and a binary file and then a PUT of a text file and a binary file.