SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Thu, 14 May 1998 15:28:29 PST8PDT
From:	"Rollin White" <rollin@scoug.com >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: FTP Server Intro

Content Type: text/plain

May 14, 1998
SCOUG Programming SIG

FTP Server Project

Overview

The purpose of this document is to introduce some of the essential
TCP/IP and FTP concepts that framed the development of this FTP server.
Each issue will be explored in more detail during the next few weeks and
months.

This project began when we first started running the SCOUG and Sundial
web sites on our own OS/2 machine. As I searched high and low for FTP
servers, I found many choices, but each of them had a fatal flaw. I
settled on one, Penguin FTPD that did the best job - but I soon
discovered it was poorly supported and had several bugs. So, I asked
myself what it would take to write my own FTP server. I examined the
appropriate RFCs and it looked like a reasonable task. I set a limit of
building a prototype in a weekend. As a result, not everything is
perfect, elegant or efficient.

TCP/IP 101

At this point, you only need a minimal understanding of TCP/IP to follow
along. The basic concept that we will use is a socket. A socket is an
abstraction for communication over TCP/IP. Sockets can be connected to
two processes on the same machine or different machines. It is this
concept that makes the Internet go round. Sockets are connected to a
specific port(or port number) on a given machine. Certain ports are
reserved for specific protocols. In our case FTP communication is
normally initiated on port 21 and data is transmitted on port 20.

Design Goals

Having just gone through all of the OS/2 FTP programs, I had a few very
specific design goals in mind. The first was Unix compatibility. The
FTP specification is fairly loose about what format the directory
listings are in, but there is a de facto standard to use the format
produced by the Unix command ls (for obvious reasons). However, some
FTP servers do not use this format. This creates problems for some
tools like FTP-PM.

Another Unix related issue was the representation of paths and drive
letters. In Unix, there are no drive letters. If a user does have
access to multiple drives, how should that be represented? In the FTPD
that comes with OS/2, they literally type "CD D:\Tmp". In others they
type "CD /d/tmp". I like the latter because it is more consistent with
the Unix format directory listings. Also, it makes it more clear what
"CD /" means.

The next issue was security. Any FTP server, including ours, should
allow a user's root directory to be something other than the root
directory. For example, if I want all users to start in E:\FTP. Most
support this, but many programs will tell the user they are in E:\FTP.
This is a security risk because it tells the user something about the
underlying directory structure of the server. By itself that
information is harmless, but to a dedicated hacker, this could be
valuable.

These two issues lead to very complicated handling of directory names
and references - an issue that I did not foresee, and a module that
could use rewriting.

Remote maintenance was an area that sorely lacked in the other FTPDs.
Many of them were designed as PM applications, where the only UI was to
show the number of current connections. I saw no need for a PM process.
Also, I wanted to allow for remotely configuring and reinitializing the
server. Initially this meant never storing configuration information in
memory - always reading from the files. That way, the files could be
manipulated remotely and the changes would take affect for future
operations. Ideally (but not implemented), there would be a telnet or
web interface for tasks such as creating users.

Environmental Factors

There are two ways an FTP Demon can run. Many start and listen to the
appropriate port for FTP connections. Others, such as the FTPD that is
included with OS/2, start a process who's only job is to listen for FTP
connections. When a connection is made, it spawns a new process to
handle that connection. There are pros and cons to each. The single
process/multi-threaded option is obviously the "OS/2" way to do it.
However, if a thread crashes, there is a good chance the entire FTPD
will crash as well. Infact, this is a significant problem with the FTPD
we are currently using. The multiprocess model takes more resources,
but it is resilient if a process crashes. Also, it slightly simplifies
design as well as makes it compatible with INETD. I chose the
multi-process model because it meant a quicker implementation - remember
I was trying to do this in a weekend!

Internal Design

The protocol for FTP (which we will examine more closely later), is
basically a command followed by one or more parameters. The server then
sends a response code and takes the appropriate action. The concept
behind the command dispatch loop is straightforward. A command string
is retrieved and broken into its parts (the command and optional
parameters). The command is compared to all known commands and
translated into an internal identifier. That identifier is used to
reference an array of functions to handle each command. The
appropriate function is called and the loop repeats.

Another key concept is a Command Structure which holds all of the
information about the connection and the command. This structure is
passed around to all of the Handle functions for manipulation.

Next meeting

This was intended to give you a quick background to the project we will
be looking at. At this month's meeting I plan to look at the actual FTP
protocol specifications as well as the implementation of some of the
aspects discussed above.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 14 | May | 1998 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.