SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sun, 16 Aug 1998 15:11:35 PDT
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 spec

Content Type: text/plain

On Sun, 16 Aug 1998 13:42:30 PST8PDT, Peter Skye wrote:

> 1. How, exactly, do you start this thing once it's written?

Probably something like:

java FtpServer 21

Where 21 is the port to listen to.

> 2. Can you show some code for just one of the methods, such as
>IsConnectionActive, so I can start remembering what Java looks like?
>And what will the main loop look like?

> 3. How many people are on this list?
>
> 4. Are you going to create stubs for everything and have us fill them
>in, or what?

Ideally yes.

> 5. What functionality is available in other FTP servers that we
>haven't designed into this one? This is an important question, since
>our _design_ might change if we know we might want to add something
>later.

I don't think any of them will affect our design that much. The ones that come to mind are:

Heavy use of user exits.
Welcome files in directories
Variable substitution in those welcome files
Support of other proticals (like TFP and HTTP)

> *****Also from the meeting:
> Extended Attribute support
> Virus Protection
> - alert administrator
> - set to unavailable until released by administrator
> - move to a different unavailable location
> Encryption of files during transmission
> Compression of files during transmission
> Text Search facility (allow user exit for administrator's
>routines)
> Recovery of partially-uploaded files
> Recovery of partially-downloaded files
> File comparison
> Random access for file reading and writing
> Email a selected file
> Move a directory tree
> Synchronize a file, directory or tree between server and client

Some of these are really features more than they are functions the FileSystem module will provide.
Some of them are too broadly defined right now. I've added several functions to accomidate those
that are clearly defined. Others, like random i/o should be supported by a well written Read/Write
file.

>Module: Connection
> Purpose: To maintain information about a given FTP client connection.
> Private Data:
> A Communication Object
> *****From the meeting
> command socket
> data port
> CurrentCommand
> CurrentDir
> A User Object
> *****From the meeting
> user i.d.
> Current stats
> Valid Logon?
> *****Methods:
> From the meeting:
> - currently logged on?
> - terminate due to user infraction or other problem?
> - maximum connections surpassed?
>
>Module: Authentication
> Purpose: To provide access authentication.
> Private Data:
> A User Object
> Methods:
> CanSee
> CanRead
> CanWrite
> CanDelete
> CanRename
> CanMove
> CanRun
> ValidLogon
> *****From the meeting:
> - password validation
> - email validation
> *****IP validation for certain functions
>
>Module: User
> Purpose: To provide access to *****persistent data about a given
>user.
> Private Data:
> UserID
> Password
> Stats
> UserType
> An Access Object
> IP Address
> Methods:
> IsLogonValid *****Is this used by Authentication.ValidLogOn ?
> RecordFileTransfer *****What is this method for?

Loging the fact that a transfer took place (I think we called it long term statistics).

> *****Where do all the extension commands go (the ones we're adding
>that aren't in RFC959)? For example, "compare these files" or
>"synchronize". Shouldn't this be a Commands module, with RFC959 as one
>of the methods? We have to plan ahead, even if we're not going to
>implement these extensions in the first release.

Actually, I was thinking of an Extension module. If a command is not recognized, it can be passed to
the Extension module. This module would be responsibile for registering and communicating with
user exits and other FTP extensions.

>
>Module: Server
> Purpose: To provide general structure and startup of FTP Server.
> (*****Private?) Data: *****?
> Methods:
> StartListen *****This listens at the assigned port (20?), yes?

Port 21, yes.

> GetConnection *****This handshakes when 20(?) says "hi", yes?

And returns a handle to that connection.

> DispatchConnection *****What does this method do? Where's the
>rollover?

Creates a new thread and appropriate objects to handle the new connection.

What do you mean by rollover?

I've made some other changes as I've started prototyping the classes. I've renamed RFC959 to
FTPCommand. I'll post the changes from your input and my work later today.

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

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 [ 16 | August | 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.