• Please review our updated Terms and Rules here

DOS FTP Server testing (You can use your web browser!)

M

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,416
Hi,

I made some changes in my TCP/IP code to make it behave better when packets are lost and it has to retransmit. The old code used to wait a fixed amount of time before retrying, which was painfully slow on a local connection. The new code is adaptive and should work much better on a wide range of connections.

If you'd like to help me test it I have my 1984 PCjr running the mTCP FTP server with some old computer pictures, some software, and some text files. (I'll add more during the day to keep it interesting.) You can connect by going to the following address:


That URL should work in most browsers (Firefox, IE and Chrome). Chrome tends to be a bit of a pig and it tries to preload the content that it finds, so if you see it going slowly it is probably due to multiple connections. The poor PCjr is only setup for 9 simultaneous connections.

If you use an FTP client anonymous FTP should work fine. Note the non-standard control port - 2021. Which also means that if you are using a real FTP client (and not a browser) you should be using PASSIVE mode. (Port mode with a non-standard control port confuses most firewalls, and they won't pick it up. Most browsers use PASSIVE mode by default.)

Uploading is not turned on for this test, but if you are dying to upload contact me and I'll give you the password.

Fun facts:

  • The machine is a PCjr with a jrIDE sidecar, 20GB IDE hard drive, WD8003 ISA Ethernet adapter, NEC V20 CPU, and an IBM PC 5150 keyboard.
  • If you want to see how the TCP/IP code is holding up you can get statistics by using the "SITE STATS" command in a suitable FTP client.
  • This is a DOS machine - you have to use DOS filenames and paths, except for the directory delimiter - that uses the standard forward slash. (Using the DOS backslash was too difficult for most clients and browsers.) Also, if you use MGET remember that you have to use *.* and not just * for a filespec.

Comments and bug reports are welcome. If the bug reports get too long or involved we can do it by email instead.


Thanks in advance,
Mike
 
Just did a test connect using filezilla. Downloaded the ZX81.jpg file, took all of 2 seconds. Everything worked A-ok.
 
That's cheating - it's a small file. ;-)

The local transfer rate is about 50KB/sec as reported by the client. Across the internet will slow things down slightly, and of course multiple users actively transferring data will really slow things down.


Mike
 
Works fine from this Andriod tablet. The Android browser decided to fire up Opera Mobile when I hit the ftp link, and that worked very well. Smooth loading. Started with the readme. I looked at several of the images, including some of the larger ones.

-Tor
 
FileZilla leech successful; average transfer rate was around 50KB/s and slowed down (but did not stop or crash) when I was trying to foul it up with directory listings at the same time. That was over a 1MB test, so I'm going again with 12MB.
 
It worked very well from Linux ftp and lftp as well as directly from Firefox. No luck from FreeBSD with lftp, and not from DOS either. Here are the messages from the DOS programs:

Code: 
O:\ $ftp 96.42.84.69
LXFTP 2.5 - HP200LX TCP/IP Suite <http://lxtcp.hplx.net/>
Type HELP for more information
looking up '96.42.84.69'...
connection attempt timed out
FTP>

D:\COMM\MTCP $ftp 96.42.84.69
mTCP FTP by M Brutman (mbbrutman@gmail.com) (C)opyright 2008-2012
  Version: May 30 2012

FTP server resolved in 0.00 seconds

Opening control connection to 96.42.84.69:21 with local port 1739
Connection failed!


Tcp: Sent 1 Rcvd 0 Retrans 2 Seq/Ack errs 0 Dropped 0
Ip: TcpRcv: 0 UdpRcv: 0 IcmpRcv: 0 Frags: 0 CSumE: 0 ProtE: 0
Packets: Sent: 4 Rcvd: 1 Dropped: 0 SndErrs: 0 LowFreeBufCount: 19

Ping works fine from both FreeBSD and DOS boxen.
 
Looking good. Just trying a few, err, non-conventional things and found the following (using Firefox 18.0).

After browsing to the SOFTWARE folder I manually inserted a space before the trailing / character. Hit enter and it still all looked OK, but now when I clicked on any sub folder it simply added that folder name to the URL but didn't go to that folder. i.e. the URL currently looks like this:

ftp://96.42.84.69:2021/SOFTWARE /PACKET/

I suppose I was expecting it to throw up something like a 550 file or folder doesn't exist error.

Steve

[Edit]
Another similar one... after selecting the SOFTWARE folder, add a space before SOFTWARE and hit enter. You are dropped back to the root folder, but the URL still ends with "/ SOFTWARE/". Now selecting a file or sub folder just adds that entries name to the URL. i.e. entering a space and then selecting PS2.GIF from the root just shows the following URL:

ftp://96.42.84.69:2021/ SOFTWARE/PS2.GIF/
[/Edit]
 
Last edited:
Ole Juul said:
It worked very well from Linux ftp and lftp as well as directly from Firefox. No luck from FreeBSD with lftp, and not from DOS either. Here are the messages from the DOS programs:

Code: 
O:\ $ftp 96.42.84.69
LXFTP 2.5 - HP200LX TCP/IP Suite <http://lxtcp.hplx.net/>
Type HELP for more information
looking up '96.42.84.69'...
connection attempt timed out
FTP>

D:\COMM\MTCP $ftp 96.42.84.69
mTCP FTP by M Brutman (mbbrutman@gmail.com) (C)opyright 2008-2012
  Version: May 30 2012

FTP server resolved in 0.00 seconds

Opening control connection to 96.42.84.69:21 with local port 1739
Connection failed!


Tcp: Sent 1 Rcvd 0 Retrans 2 Seq/Ack errs 0 Dropped 0
Ip: TcpRcv: 0 UdpRcv: 0 IcmpRcv: 0 Frags: 0 CSumE: 0 ProtE: 0
Packets: Sent: 4 Rcvd: 1 Dropped: 0 SndErrs: 0 LowFreeBufCount: 19

Ping works fine from both FreeBSD and DOS boxen.
Click to expand...
Is there a way to specify the port number in the dos ftp client? It probably tries to connect to standard port 21, while the server is set up with port 2021
 
Very nice. I downloaded the /TXTFILEs/TECH directory, which was about 3.2mb. The connection was closed two times during the download, maybe just because of others downloading files. Other than that, all downloaded just fine.
 
Ole Juul,

Your screen capture does not show you specifying the port to use, which is 2021. The standard port is 21, but I'm not using that because my ISP blocks it.

The mTCP FTP client can be told to use a non-standard port with the "-port" option:

ftp -port 2021 96.42.84.69​


Mike
 
SteveH,

I can't tell until I look at the logs (or recreate it on another machine) but I suspect that problem has more to do with the way the client encodes the path. Firefox did it for me here too, so it is easy to recreate.

Spaces are not legal in DOS filenames. I'm sure my code is parsing the directory up to the first whitespace character, and then throwing the rest of the command away. Meanwhile, the client is caching the new directory name because it thinks it was successful ...


Mike
 
mbbrutman said:
That's cheating - it's a small file. ;-)

The local transfer rate is about 50KB/sec as reported by the client. Across the internet will slow things down slightly, and of course multiple users actively transferring data will really slow things down.


Mike
Click to expand...

Just giving it an MOC. Didn't want to get in the way of the heavy-hitters that know how to put it through it's hoops. :)
 
I wouldn't worry about breaking it. Getting it featured on Slashdot would just result in a DoS attack on a DOS machine.

(Sorry, could not resist the pun.)

Multiple people hitting it concurrently gives it a good workout. So feel free to click and visit again, and peruse some of the files - I'm adding more to it to keep it interesting.

Right now it is up to 270 visits with 585 files downloaded. TCP/IP on the machine has sent 62495 packets, of which 664 of them were presumed lost and had to be resent. So that is a little over a 1% loss rate, which is good considering the global nature of the Internet and the age of the machine.


Mike
 
mbbrutman said:
Your screen capture does not show you specifying the port to use, which is 2021. The standard port is 21, but I'm not using that because my ISP blocks it.
Click to expand...

Oops. Sorry for the oversight. I mentally carried the numbers over to the other machines and forgot about the port. I just checked it now, and it works very well in both FreeBSD and mTCP. :)
 
Hi everybody,

It's still going! The current statistics from the "SITE STATS" command are:

lftp 192.168.2.134:/software/mtcp> site stats
211-Stats: Started: Sun Feb 17 11:56:14 2013, DOS version: 3.30
Sessions: 440 Active: 1 Timeouts: 63
LIST: 375 NLST: 11 RETR: 1091
STOR: 19 STOU: 0 APPE: 0
Tcp Sockets used: 2 free: 18
Tcp: Sent 106490 Rcvd 71040 Retrans 1102 Seq/Ack errs 524 Dropped 5
Packets: Sent: 108194 Rcvd: 75056 Dropped: 9 LowFreeBufCount: 0
211 OK

That's 440 connections, 386 file lists, and 1091 files sent. I uploaded 19 more files. The TCP retransmit rate is just over 1%.

The "TCP Dropped 5" count is a bad thing - that means that at some point a specific socket connection got overwhelmed with data and the data was just thrown away. This is not supposed to happen; I don't know what caused it but a client that does not respect the TCP window size can do it. On the "Packets" line the dropped 9 indicates that the software ran out of TCP buffers and those nine packets were thrown away too. Running FileZilla on my local network and uploading has caused this behavior in the past, so I'm pretty sure that I caused it, but I need to recreate it and see what went wrong.

If you have not had a chance to force your very own TCP retransmit the machine will be running all day. Feel free to hit it from any device you have that can do FTP. (My cell phone worked well against it - and with the high latency data connection it is actually a very good test.)



Mike
 
Hey Mike
I downloaded your entire Software folder using Filezilla. Upon inspection of Filezilla's Log, only one unexpected error occurred. Here's the relevant portion of the Log:

Status: Starting download of /SOFTWARE/PCJR/MESA286J.ARC
Command: PASV
Response: 227 Entering Passive Mode (96,42,84,69,9,224)
Command: RETR MESA286J.ARC
Response: 425 Cant open connection - please try again
Error: File transfer failed

during the transfer I did a "site stats". The results follow here:

Command: site stats
Response: 211-Stats: Started: Sun Feb 17 11:56:14 2013, DOS version: 3.30
Response: Sessions: 546 Active: 3 Timeouts: 85
Response: LIST: 522 NLST: 18 RETR: 1712
Response: STOR: 19 STOU: 0 APPE: 0
Response: Tcp Sockets used: 6 free: 14
Response: Tcp: Sent 158029 Rcvd 107145 Retrans 2104 Seq/Ack errs 588 Dropped 5
Response: Packets: Sent: 160900 Rcvd: 111661 Dropped: 9 LowFreeBufCount: 0
Response: 211 OK

This may have triggered the error because it was executed shortly before the error occurred. I performed another "site stats" after the transfer was complete:

Command: site stats
Response: 211-Stats: Started: Sun Feb 17 11:56:14 2013, DOS version: 3.30
Response: Sessions: 547 Active: 1 Timeouts: 86
Response: LIST: 528 NLST: 18 RETR: 1797
Response: STOR: 19 STOU: 0 APPE: 0
Response: Tcp Sockets used: 2 free: 18
Response: Tcp: Sent 161799 Rcvd 109373 Retrans 2141 Seq/Ack errs 595 Dropped 5
Response: Packets: Sent: 164715 Rcvd: 113896 Dropped: 9 LowFreeBufCount: 0
Response: 211 OK

Let me know if you would like to see the entire Filezilla Log. I can send it by PM if you'd like.

Regards

Greg
 
A 425 error happens when the server is low on resources; specifically socket connections. FileZilla does parallel downloads unless told otherwise, so it is possible that between you and another person there was just not enough sockets available.

A client is supposed to see the 425, realize that it is a temporary problem, and then try again in a few minutes. But with most machines being so big today, most clients don't even contemplate that a 425 can occur.
 
I did some additional testing with the 'curl' tool, everything works fine. (curl uses libcurl, which is used of the http/ftp/<lots> protocol client handling in tons of software.)
I also used curl via a Squid proxy, and that also worked fine. Got 18KB/s download speed btw (or instant, after the second load through the proxy of course).

-Tor
 
You must log in or register to reply here.
Back
Top