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.Introduction
2.The Programs
3.FtpProxy explained
4.FtpHack explained
5.jftpd explained
6.Comparison
7.Framework Development
First Framework
Second Framework
Third Framework
8.Conclusions
9.Resources
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-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:
FtpHack by Matteo Baccan
URL:
jftpd by Ryan Heise
URL:
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.
[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.
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.
FtpProxy / FtpHack / jftpdServer Sockets / 2 / 1 / 1
Sockets / 2 / 1 / 1
Ports / 2 / 1 / 2
Read and Write on Sockets / No / Yes / Yes
Read or Write on Sockets / Yes / No / No
Original Number of Classes / 4 / 2 / 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 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.
[UML Diagram of FtpProxy v1]
[FTPFramework v1]
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.
[UML Diagram of FtpProxy v2]
[UML Diagram of FtpHack v1]
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 ftp-related 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:
oWe removed the DataConnect class from FtpFramework and returned it to FtpProxy.
oWe 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.
oWe 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 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]
[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. 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:
FtpHack by Matteo Baccan
URL:
jftpd by Ryan Heise
URL:
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.
1