Framework Development of FTP Programs
Mini Project – Report
Jack Brown
Marcel Kunath
James Vanderhyde
Michigan State University
CSE 870 Advanced Software Engineering
Spring 2001
Instructor: Dr. B. Cheng
April 30, 2001
1.
2.
3.
4.
5.
6.
7.
Introduction ................................................................................................................. 2
The Programs .............................................................................................................. 3
FtpProxy explained ..................................................................................................... 3
FtpHack explained ...................................................................................................... 4
jftpd explained ............................................................................................................ 5
Comparison ................................................................................................................. 5
Framework Development............................................................................................ 6
First Framework .............................................................................................................. 6
Second Framework ......................................................................................................... 8
Third Framework .......................................................................................................... 10
8. Conclusions ............................................................................................................... 12
9. Resources .................................................................................................................. 13
The intend of the mini-project was to find source code of three proxy programs and build
a black box framework for these implementations. The process was to include iterations
of our framework and the refining of it by including one program after another in our
revisions. We had chosen to work with FTP proxies but were unable to find three
substantially different programs, which handled this task. We eventually opted to work
with one FTP proxy program, a password-checking program for an FTP server, and a
FTP server program itself.
This document covers the path we have taken during our study and development of the
FTP framework. It gives information on the code of the program, the functionality they
have, the differences between them and how it affected our choices we made when
implementing revisions of an FTP framework. We as well included multiple visuals,
which shall detail how the programs and framework interact by the use of UML class
diagrams. The paper concludes with a summary of our findings and judgment on how
successful we were in regards to building a black box FTP framework.
1. Introduction
This project centered around the client-server communication in the network
environment. When using file transfer agents, the clients, a user initiates a computer to
open a socket with which it communicates with another machine. The other machine, the
server, has a daemon running which provides capabilities to that machine to allow remote
login and file transfers in and out of the machine.
If a user’s machine is protected by a firewall it means certain ports are unavailable to the
user’s machine for communication. The standard communication port for FTP access is
port 21. If port 21 is blocked then no ftp communication can occur unless you access an
ftp server set to a different port or use a proxy to relay communication between a user’s
machine and a server which allows only access on the specific blocked port. This proxy
method creates two communication streams. One is between the user and the proxy
server and the other between the proxy server and the real destination FTP server. The
proxy is meant to forward any control and data communication between server and client.
Control packets are the data specifying what client commands to execute on the server
and the data packets are the data that gets relayed when a file is being transferred.
We were unable to find three different FTP proxy programs and opted for an additional
hack program, which creates connections to FTP servers and checks on login if a
password out of a database matches. The third program is a FTP server program, which
allows for serving FTP access to a host.
To make our endeavor clear we included UML diagrams of our programs and framework
revisions. UML is the Unified Modeling Language, a general-purpose notational
language for specifying and visualizing complex software, especially large, object-
2
oriented projects. The diagrams are to assist you in understanding what functions the
programs provide and how we came up with the framework by moving non-program
specific components from programs itself into our framework.
The second tool that we used to facilitate the design of our framework was the Factory
Design Pattern. Design Patterns, in general, “identify, name, and abstract common
themes in object-oriented design.” The Factory Design Pattern “defines the operations
that create specific product objects.”
Finally, as a definition of our project: A framework is an integrated set of components
that collaborate to provide a reusable architecture for a family of reusable applications.
2. The Programs
We have selected the following three programs for our framework exercise:
FtpProxy by Christian Schmidt
URL: http://christianschmidt.dk/index.php?id=103
FtpHack by Matteo Baccan
URL: http://www.infomedia.it/artic/Baccan/opensource/ftphack012.zip
jftpd by Ryan Heise
URL: http://www.progsoc.uts.edu.au/~rheise/projects/jftpd/
3. FtpProxy explained
FtpProxy is a program, which allows handshaking between a client user protected from
accessing ftp servers and an ftp server out of the reach of the client user.
3
[FtpProxy Functionality]
The client instantiates a connection to the FtpProxy server on a port available to the client
using skControlClient socket. After the connection was established the FtpProxy server is
fed information to which ftp server to connect to using what login and password. This
connection is done using the skControlServer socket. The FtpProxy server streams the
control data back and forth between the ftp client and server on the paths called osClient
and osServer. This allows them to create a separate data connection using skDataClient
and skDataServer sockets to tunnel information packets through the FtpProxy server. The
streams for the data flow are rClient and rServer.
4. FtpHack explained
FtpHack is a multi-threaded program, which allows to check a login name on a server to
be checked against a password database (text file). The client program accesses a server
and starts multiple threads, which all have simultaneous access to the password database.
The concurrency makes use of the threads ability to keep scope of what passwords have
been checked and still have to be checked. The threads simultaneously make login
attempts into the server until all passwords were tried, a login succeeds, or the user
terminates. The program has small overhead due to the threading in case a password
matches. The program does terminate with slight delay and keeps checking passwords
until all threads are aware that one password was a match. The match notice has to
propagate to the other threads and give them a chance to terminate for the program to
terminate successfully.
4
5. jftpd explained
The jftpd server is a multi-threaded ftp server listening on port 21. For each connection
request a new thread is started called ServerPI. Associated with this thread is ServerDTP,
which is an object handling the actual data transmission.
Communication between client occurs via two separate socket connections as shown in
the following diagram:
------------|/---------\|
||
User ||
-------||Interface|<--->| User |
|\----^----/|
----------------|
|
|
|/------\| FTP Commands |/----V----\|
||Server|<---------------->|
User ||
|| PI ||
FTP Replies ||
PI
||
|\--^---/|
|\----^----/|
|
|
|
|
|
|
-------|/--V---\|
Data
|/----V----\|
-------| File |<--->|Server|<---------------->| User
|<--->| File |
|System|
|| DTP ||
Connection
||
DTP
||
|System|
-------|\------/|
|\---------/|
----------------------------Server-FTP
USER-FTP
[diagram from RFC 959]
jftpd is an implementation of the left hand side of this diagram. The user can use any
client to connect to jftpd, which complies with the RFC standard.
6. Comparison
The following table shall give an easy overview of what each program requires for it to
work and what functionality it holds.
Server Sockets
Sockets
Ports
Read and Write on Sockets
Read or Write on Sockets
Original Number of Classes
FtpProxy
FtpHack
jftpd
2
2
2
No
Yes
4
1
1
1
Yes
No
2
1
1
2
Yes
No
15
To develop a framework we needed to distinguish what general functionality an ftp
program has and what components can be re-used by all specific programs. All programs
5
use at least one server socket and one socket. This should be guiding our general layout
for the framework.
We decided to as well include the more special socket use of FtpProxy as well in the
framework because of time and coding constraints. To generalize to a subset of sockets
for the framework would mean a coding change in the FtpProxy program.
This may make our framework larger than usual but it allows for all functionality to be
included at minimum cost (time and coding). This functionality and requirements
comparison was the main decision and committal phase for our framework.
In addition, we moved the data transfer portions of FtpProxy and jftpd into the
framework. This allowed us to centralize data transfer into the framework. (FtpHack had
no data transfer.) We wanted, also, to move the control/login portions of all programs
into the framework. However, we were unable to do so because of the unique way that
FtpHack uses multiple threads to conduct an ftp login.
7. Framework Development
First Framework
Our first application that we used to construct our framework was FtpProxy (described in
Section 3 above). We selected this application first because it was the only version of an
ftp proxy with source code that we could find. The FtpProxy in its original form extends
the class Thread. We intended to build a framework called FtpFramework, which extends
the same Thread class. And then, we instantiated the FtpProxy application by extending
the FtpFramework class. Because we subclass FtpProxy from FtpFramework,
FtpFramework is a white box framework at this stage. See the two diagrams below that
contain the UML diagrams of our FtpProxy application and our FtpFramework
framework, respectively.
6
[UML Diagram of FtpProxy v1]
[FTPFramework v1]
7
Second Framework
The second application that we used to further develop our framework was FtpHack
(described in Section 4 above). After failing to find any other ftp proxy application, we
selected FtpHack because it was one of the smaller applications that we found and that
had some features in common with FtpProxy.
[FTPFramework v2]
Above is the UML diagram of our second FtpFramework. FtpHack is such a simple
application that our framework required very few changes. The main difference between
the first and the second FtpFramework is that we removed the DataConnect class from
FtpProxy and added it to FtpFramework. Also, we removed some access methods from
FtpHack and added them to the framework. Because of the complexity of FtpHack
spawning up to ten threads, we spent considerable time debugging the new FtpHack
application. In this second version of the framework, we used inheritance to instantiate
both the FtpHack and FtpProxy application. Thus, our framework was still white box.
Below are the two UML diagrams for our new FtpProxy and FtpHack applications.
8
[UML Diagram of FtpProxy v2]
[UML Diagram of FtpHack v1]
9
Third Framework
The last application that we used to develop our framework was jftpd (described in
Section 5 above). We selected the jftpd application because it was the smallest ftprelated application that was not already a framework and that had some features in
common with FtpProxy.
[FTPFramework v3]
Above is the UML diagram of our third FtpFramework. Because of the size of the jftpd
application, we significantly changed our framework. The main differences between the
second and the third FtpFramework are:
o We removed the DataConnect class from FtpFramework and returned it to
FtpProxy.
o We removed many classes from jftpd and added them to our framework. These
classes are TransmissionHandlerFactory, TransmissionHandler,
StreamTransmissionHandler, RepresentationFactory, Representation,
AsciiRepresentation, AsciiInputStream, AsciiOutputStream,
ImageRepresentation, and ParseException. This last class gave some fault
tolerance to our framework.
o We created a public Interface called Configurable that allows applications to
configure certain parameters.
In this third version of the framework, we used inheritance and some implementation to
instantiate all three applications. Thus, our framework became gray box. Below are the
10
two UML diagrams for our new FtpProxy and jftpd applications. (The UML diagram of
the FtpHack application did not change.)
[UML Diagram of FtpProxy v3]
11
[UML Diagram of jftpd v1]
8. Conclusions
In this mini project, we attempted to find three FTP proxy applications with Java source
code. Since we could only find one, we selected two FTP applications, although we
again had some difficulty finding a small non-framework FTP application for our third
application. Starting with the FTP proxy application, we constructed a white box
framework. Adding the second application (an FTP client) and modifying the framework
was not difficult, although the framework was still white box. Finally, we modified the
framework to incorporate the third application (an FTP server), which resulted in a gray
box framework.
One of the lessons we learned was the importance of starting with the right application.
We felt that the third application would have been a better application to use to start
modeling our framework, even though it was not a proxy. The reason was that the third
application was the largest by far.
Also, we began to understand the difference between white box and black box
frameworks. A white box framework has classes that a new application must extend.
12
We wanted to turn our framework into a black box framework by creating interfaces for
the application to implement. This would be convenient because it could make for a
much cleaner and easier implementation on the part of the application developer.
However, this proved more difficult than we expected. The functionality of the FTP
applications seemed to be wrapped up in the instance variables, and so we abstracted a lot
of these out to an abstract class in the framework. This made a very nice white box
approach, but we found it quite difficult to abstract the functionality into function calls
that each application would implement.
9. Resources
FtpProxy by Christian Schmidt
URL: http://christianschmidt.dk/index.php?id=103
FtpHack by Matteo Baccan
URL: http://www.infomedia.it/artic/Baccan/opensource/ftphack012.zip
jftpd by Ryan Heise
URL: http://www.progsoc.uts.edu.au/~rheise/projects/jftpd/
The UML User Guide, G. Booch, J. Rumbaugh, and I. Jacobson, 1998, Addison-Wesley.
Design Patterns: Elements of Reusable Object-Oriented Software, E. Gamma, R. Helm,
R. Johnson, and J. Vlissides, 1995, Addison-Wesley.
13