«

I've written an FTP server and am wondering how I am supposed to test it.

I'm the author so I know what I'm doing and how the server is and isn't
supposed to work, but there are idiots out there who will undoubtedly
mess things up.

So how I do I test it, other than connecting different clients to it and
uploading/download files?

Does anyone have enough time and willpower to help me test the thing?
I'm most curious to see how well my virtual filesystem works (map two+
physical directories to one virtual directory...).

On Tue, 11 Oct 2005 17:59:50 +0000, EdwardH wrote:

> I've written an FTP server and am wondering how I am supposed to test it.

Well, one test i like to do to unwary applications is just sending a lot
of "noise" (random data), and see if it recovers gracefully from such
things as embedded nils, and so on. For even more fun, do so after
successfully authenticating (at least as anonymous).

> So how I do I test it, other than connecting different clients to it and
> uploading/download files?

Create a lot of load using a script that "hammers" the server with
connects. Upload / Download files with unusual lengths. Do about every
part of the protocol wrong, violate every restriction you find.

> Does anyone have enough time and willpower to help me test the thing?
> I'm most curious to see how well my virtual filesystem works (map two+
> physical directories to one virtual directory...).

Switch between the two like there is no tomorrow. Play with different
permissions on both directories (on the actual fs). In short, be evil.

--
You can't run away forever,
But there's nothing wrong with getting a good head start.
--- Jim Steinman, "Rock and Roll Dreams Come Through"

EdwardH wrote:
> I've written an FTP server and am wondering how I am supposed to test it.
>
> I'm the author so I know what I'm doing and how the server is and isn't
> supposed to work, but there are idiots out there who will undoubtedly
> mess things up.
>
> So how I do I test it, other than connecting different clients to it and
> uploading/download files?
>
> Does anyone have enough time and willpower to help me test the thing?
> I'm most curious to see how well my virtual filesystem works (map two+
> physical directories to one virtual directory...).

Have you tried "wget" from a few machines?


--
Yu Song

/* E-mail.c */

#define User "Yu.Song"
#define At '@'
#define Host "warwick.ac.uk"

int main() {
printf("Yu Song's E-mail: %s%c%s", User, At, Host);
return 0;}

/*

Further Info. : http://www.dcs.warwick.ac.uk/~yu/

*/

On Tue, 11 Oct 2005 17:59:50 GMT, EdwardH
<edwardh@N:O:S:A:M:edward.dyndns.org> wrote or quoted :

>I've written an FTP server and am wondering how I am supposed to test it.

from a practical point of view, you want to download a variety of
popular FTP clients and make sure you can do the basic functions from
each.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

I tested my server with the AbsoluteFTP windows client.

Apparently, AbsoluteFTP seems to think that spaces in the file names are
actually question marks. Needless to say, my server couldn't find the
files AbsoluteFTP wanted.

Is it correct behavior to replace spaces with question marks?

On Wed, 12 Oct 2005 01:12:30 +0000, EdwardH wrote:

> I tested my server with the AbsoluteFTP windows client.
>
> Apparently, AbsoluteFTP seems to think that spaces in the file names are
> actually question marks. Needless to say, my server couldn't find the
> files AbsoluteFTP wanted.
>
> Is it correct behavior to replace spaces with question marks?

Question marks, or unprintable characters mapped to an error glyph that
looks like a question mark? Print the bytes and see that it's actually
0x20 at that location in the name.

AbsoluteFTP may well be assuming that the FTP server expands glob patterns
(eg., ? as a single-character wildcard, * as a 0..n character wildcard,
see the glob(3) man page). RFC 959 (File Transfer Protocol) is mute on
the subject, except to describe the syntax of RETR:

RETR <SP> <pathname> <CRLF>

and <pathname>:

<pathname> ::= <string>
<string> ::= <char> | <char><string>
<char> ::= any of the 128 ASCII characters except <CR> and <LF>

RFC 959 does not appear to have been superceded, except with regards to
security features and internationalisation; RFC 2640 (Internationalization
of the File Transfer Protocol) makes no mention of wildcards.

In short, I think AbsoluteFTP is taking advantage of a common
implementation quirk that is outside the FTP standard.

-Owen

> In short, I think AbsoluteFTP is taking advantage of a common
> implementation quirk that is outside the FTP standard.

I kinda figured the same thing.

Which is bad

Bad AbsoluteFTP! Bad!

Maybe I'll mail them and ask them what they're doing.

Thanks for the help.

On Wed, 12 Oct 2005 09:17:41 GMT, EdwardH
<edwardh@N:O:S:A:M:edward.dyndns.org> wrote or quoted :

>> In short, I think AbsoluteFTP is taking advantage of a common
>> implementation quirk that is outside the FTP standard.

This is a common problem is all documentation. People are TERRIFIED to
ever say "This package/class/method/protocol does NOT do so and so"
even when 25% of sane folk naturally assume it MIGHT.

It drives me nuts looking in vain for a natural feature that is simply
not there. Salespeople censored such information out of all the
materials I wrote when I worked for Univac. If you write a response
to an RFP and you don't have a feature the customer asks about,
salespeople want to simply omit any reference rather than answer the
question or requirement directly. I figured I was helping the customer
in his the evaluation giving him the straight goods rather than making
him dig. I also figured it would build trust.

The salesperson's idea is to hope the customer does not notice until
he has signed.

--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.