• Please review our updated Terms and Rules here

Admin Requirements for DOS FTP Server

M

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,418
If you were (or are) looking for an FTP server running under DOS, what would you be looking for?

Some things on my list:

  • Multiple clients (3 to 10) online at the same time
  • Multiple users with passwords via a userid/password file.
  • Configurable permissions per user. (Can a user upload? Can they only upload to a specific directory?)
  • Anonymous FTP
  • The ability to limit a user to a directory (and its subdirectories) on a hard drive. (Kind of like a sandbox, or chroot support on Unix boxes.)
  • Some customization on server messages.
  • Logging of connections and data transfers in a somewhat easy to parse format for later analysis.


I am looking for other ideas on things like how to manage the machine while keeping it running. For example, the ability to add users on the fly without taking the FTP server down would be nice.


Mike
 
The ability to use a port other then the standard 21
The ability to check archived files uploaded for virus

DOS is very limited because of partition size (2GB), so if you could use a different drive partition for each sub directory you could use a much larger hard drive.
 
Unknown_K said:
The ability to use a port other then the standard 21
The ability to check archived files uploaded for virus

DOS is very limited because of partition size (2GB), so if you could use a different drive partition for each sub directory you could use a much larger hard drive.
Click to expand...

Two good points ...

The port configuration is done already - that's a common requirement because of firewalls and ISP blocking. Besides the control port one needs to be able to configure the range of data ports that will be used to make it easier to configure firewalls.

Virus scanning desirable, but probably not feasible. Performance on older machines is too limited to do that in real time and you need a current source of anti-virus fingerprints/data. The anti-virus data alone would be bigger than the hard drives on the machines.
 
I was thinking more of the old virus stuff that was around in the DOS era, not like stuff that needs windows or directx java etc to function will hurt a DOS machine at all. You can use an old DOS based AV with the old definitions to scan old *.zip files for common virii that were around when floppies were still cool.

Why else would you bother using a DOS FTP unless you were going to host old DOS era files found on the web or other FTP sites?

I currently use FTP Serv-U enterprise non expiring free upgrades (purchased for $25 when it was shareware) and now costs a bunch of money. Still it would be cool to host some ancient DOS files (8.3 format) on a DOS or NOVELL based FTP server. Speaking of the 8.3 filename issue, how about being able to include a NFO file in the zipped upload with a description of the what the file is that the FTP program can display somehow?

The only other thing I could think of is being able to use NTFS drives for storage to get around space limitation (how you would trick DOS to do with I do not know, maybe a network share to another machine?).
 
your current list has all the important features covered. mine does all that other than the logging. ;-0
 
If it does all of that and it is done, why aren't you distributing it?

I'm kind of expecting that my version of an FTP server is going to be faster and more stable because I'm not dealing with a TSR based TCP/IP stack.
 
i think i posted it on here a long time ago. it's not an FTP-only server. it's also HTTP w/ virtual host by domain name support. yours will be better, i'm sure.

http://rubbermallet.org/qsv11rc1.zip

you can change the config file so that can disable either HTTP or FTP so precious CPU time isn't spent polling for connections that you won't have. i made it a dual protocol server because i wanted to run a small website on an 8088, but also wanted to be able to change the content without downtime. i wrote it in late 2008.

it has a pretty fancy UI that can chew up quite a few CPU cycles, but there's a command line switch /FAST that isn't documented in the readme. it disables the fancier display and just prints info line by line via stdout. data throughput is several times faster on really old PCs if you use that.
 
Ah, Quickserv .. I remember it. You have a web server posted but not this one.

  • How many concurrent connections does it handle? How well did it do with multiple file transfers at the same time?
  • Does it do both PASV and PORT FTP transfers?
  • Did you have problems with NAT/firewalls? (I bumped into an interesting one tonight with PASV responses through a firewall.)

I'm doing an FTP server for similar reasons - I want to be able to do maintenance on the BBS while it's still running. And some limited file serving for the BBS would be nice.


Mike
 
yes, PASV and PORT are both supported. EZNOS and others have issues with NAT if it isn't a DMZ host or directly connected to the net because it will only report it's internal LAN IP. you can optionally specify the IP to report to clients in the config file for mine, so it is fine behind a router. it'll do up to 8 simultaneous connections for each protocol. i've tested it by running ALL of them with a huge file one time. it didn't seem to have any problems.
 
I ran into the NAT/DMZ issue last night and implemented the same work-around before I even looked to see how others handled it. (The work around is to tell the program what IP address to report for PASV responses.) I think I am going to finesse it today by only lying on PASV responses going to foreign networks; if you are on the same subnet lying about the IP address breaks the local machines.

Trumpet must be better about handling incoming socket connections than my code. To make sure that every client can do what it needs to at all times, I have three sockets per client - one for the control connection, one for the data connection, and one socket to listen for new data connections if the user is using PASV mode. If you had eight FTP users all try to do a PASV transfer at the same time that would require 24 sockets, plus the main listening socket that accepts new control connections.

I thought you were limited by the number of sockets that Trumpet could allocate - did it do something where listening sockets were not counted the same way as data sockets, thus making it cheaper to listen on multiple ports at the same time?

HTTP makes this easier - one socket and short connections. :)
 
Eh, I can't resist the urge to do a little premature testing. It's running on a PCjr right now. You can get to it by connecting to --.--.---.-- on port --.

For browsers the url looks like: ftp://--.--.---.--:----/ . That will let you browse using anonymous FTP from Firefox, Internet Explorer, etc.

For the windows XP FTP client just start ftp without the IP address, and when you get an ftp prompt use "open --.--.---.-- ----" as the first command. For better FTP clients, you can specify the port on the command line.

There is a PCjr specific directory underneath 'SOFTWARE' . If you are inclined you can use anonymous FTP to upload to the 'incoming' directory too. I'll be adding more over the next day or two.

This is a limited time offer - I don't want to leave the Jr on for too many days.


Mike
 
Last edited:
No problem browsing using Firefox, but had problems from a WinXP DOS box. Connected OK to port 2021 with user anonymous, but whenever I entered the command LS or DIR, all I got was:-

ftp> ls
200 PORT command successful
425 Cant open connection - please try again
ftp> dir
200 PORT command successful
425 Cant open connection - please try again
ftp> cd SOFTWARE
250 CWD command successful
ftp> dir
200 PORT command successful
425 Cant open connection - please try again

Just in case it was to do with the other commands I tried before the above, they were:-

quote help
and
quote site

The first gave me your very helpful help message, the latter gave me 500 Syntax error: SITE


Steve
 
If you are behind a firewall you need to use PASSIVE (PASV) mode. The Win XP client doesn't do PASV, so it only works if you are directly connected without a firewall. I shouldn't have even acknowledged it exists .. that was misleading.

I should add the SITE COMMAND ..

Just for grins, try QUOTE SRVSTAT sometime ..


Mike
 
Thanks!

It's been up almost 21 hours. Here are the current stats:

Sessions: 285 Active: 1 TcpSockets used: 2 free: 15
Tcp: Sent 19203 Rcvd 14823 Retrans 77 Seq/Ack errs 50 Dropped 0
Packets: Sent: 19403 Rcvd: 15426 Dropped: 0 LowFreeBufCount: 28

So that's 19000+ packets sent, and almost 15000 packets received. The retransmit rate isn't too bad - 77 packets on 19203 total packets is only a 0.4% drop rate. Considering the speed of the machine and the terrible hard drive it has, that's actually very good. (The hard drive is parallel port attached, which is very bad for performance. That and DOS 5 occasionally takes a timeout while it computes free disk space, resulting in 5 to 10 second pauses.)

LowFreeBufCount tells me that I never used more than 12 of the incoming receive buffers. (I allocated 40, and never got below 28 available.) That's good information too.

Keep it coming! The first round of testing was done with a very small group, and it broke a few things. (I was losing track of socket data structures over time - found that bug, but it was difficult.) This round of testing has not identified any major problems yet.


Mike
 
Just to try and nail your server, I pulled down everything on the FTP from my office's OC-3 this afternoon using an old version of WS-FTP LE... worked like a charm! Also was able to navigate using Firefox in XP without any troubles.
 
It's been up about 2.5 days now. Here are the current stats:

Sessions: 418 Active: 1 TcpSockets used: 2 free: 15
Tcp: Sent 52198 Rcvd 36347 Retrans 186 Seq/Ack errs 99 Dropped 0
Packets: Sent: 52618 Rcvd: 38197 Dropped: 0 LowFreeBufCount: 28


I doubt there have been a lot of concurrent users, but that is probably a good thing - it doesn't have a lot of bandwidth to split. It doesn't appear to be leaking memory or misbehaving in any significant way, so I'm satisfied.

Here are some things I am going to change for next time:

  • Add a directory cache so that the directories that get viewed the most are cached instead of generated each time. Generating a directory is a major CPU activity so this will make things a little smoother.
  • Give the operator the ability to limit the number of active data transfers. On faster machines this is not an issue, but a PCjr or a PC XT trying to service more than 3 or 4 active data transfers would work, but would be a frustrating experience.
  • Add statistics to see the number of gets, puts, etc.


The machine will be running until late this evening. If you haven't had a chance to connect to the world's only PCjr FTP server, don't miss it! For browser users the URL is ftp://--.--.--.--:----/ . If you have command line FTP you'll have to enter the non-standard port. And if you have a personal firewall, you probably need to use PASSIVE mode to get directory listings or send/receive files.


Mike
 
Last edited:
You must log in or register to reply here.
Back
Top