SCOUG-Programming Mailing List Archives
Return to [ 29 |
May |
1998 ]
<< Previous Message <<
>> Next Message >>
Content Type: text/plain
Peter Pontificated on What Rollin Wrote as follows:
Rollin White wrote:
> As I searched high and low for FTP
> servers, I found many choices, but each of them had a fatal flaw.
What, typically, did the coders miss or mess up?
> I asked
> myself what it would take to write my own FTP server. I examined the
> appropriate RFCs
I'd like to look at those RFCs (they're at
ftp://ds.internic.net/rfc/rfc####.txt). Do you still know the 4-digit
RFC numbers?
[pause, insert earlier message to list from Greg...]
I have done some browsing and have found some information of
interest about FTP. The RFC for the protocol is number 959 and
is online at:
ftp://ftp.isi.edu/in-notes/rfc959.txt
--
Gregory W. Smith (WD9GAY) gsmith@well.com
[/pause -- we now return to your regularly scheduled e-mail :) ]
> Sockets can be connected to
> two processes on the same machine or different machines. Sockets are
connected to a
> specific port(or port number) on a given machine.
I understand that a socket is connected to a "soft" port for network
communications. I don't understand how a socket can connect to two
processes on the same machine since there's only one socket to plug
into, unless you just mean that the two processes use the same socket.
Is that it?
[TE] Think of a socket as a "pipe" [only from a "physical" point of view
-- "pipes" are another "unix" construct] There are two ends to a pipe --
something put in one end has to come out the other...
> Another Unix related issue was the representation of paths and drive
> letters. In Unix, there are no drive letters.
How do you access drives in Unix? With a number? Or is the Unix file
system very different (spanning, etc.)?
[TE] In Unix, there are two non-overlapping definitions of the word
"root" -- from the file systems point of view, "root" means, literally,
the "root" of the directory tree. From a process (i.e., "user")
standpoint, "root" means (essentially) the system manager. (also
referred to as the "superuser")
In the "dos" world, each physical drive has it's own "root". In Unix,
one drive (partition) is defined as the "root", and within that directory
tree the system administrator will create a directory and MOUNT another
physical drive at that (logical) location. That "other drive
(partition)"'s "root" then attaches to the overall directory tree at the
subdirectory point.
example:
Using a "1-gig" drive as the primary drive and a "4-gig" drive as the
secondary, the "1-gig" drive partitioned into two 500-meg partitions,
the "4-gig" drive partitioned into a 1-gig and a 3-gig partition
Partition 1 of drive 1 [using "1" based numbering rather than "0"], which
under "normal" circumstances would be a DOS "boot" partition, is the
"root" partition. The root partition will contain directories such as
"/bin", "/etc", and possibly one or two others that are REQUIRED for
booting to occur. Other directories may be included. Since this
partition is 500 meg, that is all that can ever be put at these "low
level" directories...
Partition 2 of drive 1 is formatted as "swap space" (linux, in
particular, makes use of such a partition). Since this is for "virtual"
memory, the partition doesn't really take up "tree" space -- it just
"exists" (other in-memory structures maintain this information)
Back on partition 1 of drive 1, two subdirectories are created -- /usr
and /var. these directories are empty.
Partition 1 of drive 2 is used as the "variable" or spool space, so this
partition would be mounted as "/var" -- any subdirectories created under
"/var" are created in this physical partition.
Partition 2 of drive 2 is mounted as the "/usr" partition -- all "user"
directories are created under this (notable directories are /usr/bin --
the equivelent of /bin, but for "user" installed programs, and
/usr/home/ -- a directory for each individual user account)
> (I like specifying the drive letter as the top level subdirectory,
i.e.)
"CD /d/tmp".
That's good. I already use such a system.
> These two issues (paths/drives and security) lead to very complicated
handling of directory names
> and references - an issue that I did not foresee, and a module that
> could use rewriting.
What those complications are would be good for a lesson.
[TE] an alternative to 'drive level' access, which takes more preperation
on the part of the administrator but is ultimately more secure, is to
define everything as "virtual" directories. By this I mean that when the
client requests the "root" directory, some directory OTHER than C:\ is
returned (this >ahem< is the approach MS takes with their personal
web/ftp server in the latest version of win95 -- at least they did ONE
thing "right" :) To allow access to "other" drives, simply create other
"virtual" directories. Using the above example, the directory "/d" CAN
refer to D:\, but it could just as easily refer to D:\DATA or G:\GAMES.
Keep in mind, however, that some mechanism (might) be needed to inform
the user that this "virtual" directory exists -- for instance, when the
client issues an "ls" command against the "root" directory, it should
return "d" as a potential directory name
As alluded to in my earlier comment, in Unix there is a concept of a
users "home" directory -- in a sense, an individuals "root" directory on
that particular machine. When logging onto a Unix FTP server as someone
OTHER than anonymous, you are typically "dropped into" your home
directory on the server. For security purposes, a similar thing can be
done where you create different "virtual" directories based upon the user
name used to log into the FTP server. (by the way, the user "root" and a
number of other "typical" unix usernames are DENIED access to the FTP
server for "security" reasons...)
> A command string
> is retrieved and broken into its parts (the command and optional
> parameters).
Is this where GetString() comes in?
> 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.
This would be good for a lesson. Can you throw the Command Structure at
us without comment at this time, so we can see what's in it and ponder
how to use it?
And an overall question. What compiler should we use? I have VisualAge
C/C++ and Watcom C/C++. Any pros/cons?
- Peter Skye
=====================================================
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".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 29 |
May |
1998 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
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.
| 
