• Please review our updated Terms and Rules here

Features for an FTP client

Implementing them locally could be a good thing. You can provide a Unix-like output format for "lls" for example. And "lcd" can change the working directory temporarily just for the session (i.e. when you end, you're where you started).

So not a bad thing.

Forgot to ask if you're sticking with local 8.3 filenames or are providing support for long filenames (e.g. as provided under DOS by DOSLFN).
 
mbbrutman said:
I do need to implement some local commands to make it more usable:
  • Change directory
  • DIR
  • rename
  • copy
  • move
  • delete
Mike
Click to expand...
Isn't there some duplication there? For example move = copy/delete and rename also = copy/delete. It seems to me you could do with just the move and delete. Skip the copy and rename.
 
Ole Juul said:
Isn't there some duplication there? For example move = copy/delete and rename also = copy/delete. It seems to me you could do with just the move and delete. Skip the copy and rename.
Click to expand...

Valid observations, but consider the following:

  • The additional code for each command is probably less than 60 bytes after it is compiled.
  • Renaming a file is far quicker and easier on the machine that copying the file (which might be large) and deleting the original copy. It also doesn't require any additional free space on the drive.
  • Same for 'Move' ...
 
mbbrutman said:
What other features should I have?
Click to expand...

Split-screen isn't necessary. The essential features for any vintage computing enthusiast would be:

  • Small .exe size (100K or smaller) so that it can fit onto a floppy if the HD isn't working
  • ASCII and binary (ASCII is necessary so that you can grab text files off of unix systems, something I do frequently)
  • hash command (or some other realtime display, updated once a second, of how the transfer is going)
  • prompt command (so that I can do an "mget *.zip" and they all come over)
  • Buffered writes (telling DOS to write 32K to disk once is faster than telling it to write 2K to disk 16 times)
Just the above would be fantastic.
 
Trixter said:
Split-screen isn't necessary. The essential features for any vintage computing enthusiast would be:

  • Small .exe size (100K or smaller) so that it can fit onto a floppy if the HD isn't working
  • ASCII and binary (ASCII is necessary so that you can grab text files off of unix systems, something I do frequently)
  • hash command (or some other realtime display, updated once a second, of how the transfer is going)
  • prompt command (so that I can do an "mget *.zip" and they all come over)
  • Buffered writes (telling DOS to write 32K to disk once is faster than telling it to write 2K to disk 16 times)
Just the above would be fantastic.
Click to expand...


Well, I'm good on the file size - still under 85K. The progress indicator is trivial to code, so that will get in. I always do buffered writes for best performance - the buffer is 16K, which provides a marginal improvement over an 8K buffer. (I learned all those tricks with my Netcat client.) Like the Netcat client, I'll probably make it an 8K buffer but have it adjustable by an environment variable.

Mget and mput are going to be interesting to implement though. You have to get the file list and store it, and that requires even more memory. And then there is the sticky problem of allowable filenames .. that will take more thought and coding.

Split screen isn't necessary, but I like it because it allows me to process asynchronous messages coming from the FTP server. Right now, when I go read keyboard input I have to stop polling for input from the server. Usually that isn't a problem, as FTP is relatively synchronous with respect to client/server interaction. I don't think I'll go split screen, but for interactive use I'm going to have to start polling the keyboard myself again instead of using MSDOS function 0x0a from INT 21.

Binary mode is already there. ASCII is obviously needed to be complete.

So based on your list, after I get mget and mput done it will be usable. :)
 
here's the DOS FTP client i use... make yours better. :)

http://rubbermallet.org/ftp65.exe


it's alright, but (very) rough around the edges. you can't even backspace typing your password in, it sends it as ASCII value 8 lol. sadly enough, this is the best one i can find.
 
Mike Chambers said:
here's the DOS FTP client i use... make yours better. :) .... ftp65.exe
it's alright, but (very) rough around the edges. you can't even backspace typing your password in, it sends it as ASCII value 8 lol. sadly enough, this is the best one i can find.
Click to expand...
Why do you use .65 when .70 is newer and much smaller? I haven't used 65 other than to try it so I don't know the real difference though, but if you think its better I'd like to know.
 
Ole Juul said:
Why do you use .65 when .70 is newer and much smaller? I haven't used 65 other than to try it so I don't know the real difference though, but if you think its better I'd like to know.
Click to expand...

v.70 is ew... for one thing, it makes the screen all white on blue. more importantly, it always seems to timeout at the end up an upload... although the file still goes through. i also find the upload speed to be about 10 times slower than 0.65

i'm not sure what the programmer was thinking, but it's far from an improvement.
 
Mike Chambers said:
v.70 is ew... for one thing, it makes the screen all white on blue. more importantly, it always seems to timeout at the end up an upload... although the file still goes through. i also find the upload speed to be about 10 times slower than 0.65
i'm not sure what the programmer was thinking, but it's far from an improvement.
Click to expand...
Great info thanks! I'll switch them right away, now that I know .65 is worth trying. I had just made an assumption based on date and size. :) Anyway, hopefully soon we'll all be using the new one!

@mbbrutman: What are you going to call it anyway? How about MFTP?
Also, MC and I are hoping it won't go all white and blue on us!
 
I know this is drifting OT but it is interesting to consider how well an FTP client hooks up with the server.

I just substituted the WFTP beta (v.65) for my usual v.70 and the result was interesting. Yes, the puts are faster and the gets, although maybe not faster, take almost no time to "complete" or put you back on the command line. A noticeable problem though is that it takes quite a long time to negotiate upon logging in, so it takes a while before one can start using it. Version .70 does not have that problem. This negotiating time is a puzzlement to me. What is it doing? Since Mike C seems to think that v.65 is OK then he is probably using a different server and that is making a difference. I'm using proftpd, what are you using Mike?

BTW, the lack of blue and white is a pleasant upgrade. However it does not recognize the wattcp.cfg file in the environment. Still, waiting for a login or waiting for a download. Six o one, half a dozen of the other. Now I don't know what to do. I really prefer everything to be instant. That's the whole idea of using computers isn't it?
 
I just had to take a quick peek at the WATTCP FTP 0.65 version. It looks very full featured. Here are some quick measurements:

Machine: 386-40 with 16 bit NE2000 card, IDE hard drive
File: 3.2MB zip file of DOS 3.3, best of 3 gets and puts

FTP 0.65: GET 13.45s, PUT 42.24s
My FTP: GET 6.87s, PUT 7.92s

So on this machine, my code is nearly 2x faster for receiving and 5x faster for sending.

I tried to run FTP 0.65 on the PCjr - it dies when reading the keyboard. That might be a PCjr specific problem. Can anybody benchmark it on an 8088 class system?
 
mbbrutman said:
I'll probably make it an 8K buffer but have it adjustable by an environment variable.
Click to expand...

Can you make it a command-line switch instead? I am always running out of environment space, and increasing it chews up DOS ram.

I don't think I'll go split screen, but for interactive use I'm going to have to start polling the keyboard myself again instead of using MSDOS function 0x0a from INT 21.
Click to expand...

I don't understand the keyboard problem. Why do you have to poll the keyboard yourself (I'm assuming by reading hardware and/or hooking the interrupt)? Isn't the BIOS-provided Int 16h good enough?
 
Right now I'm letting MS DOS provide me keyboard input. Which is great, but it's a blocking call. I can't poll my TCP sockets while that is happening.

I'll probably be using BIOS calls to get around that. Which means I have to do my own editing functions (again).
 
Version 0.70 is slightly faster than 0.65 when receiving, but it seriously broken when sending. Here are my latest numbers:

Machine: 386-40 with 16 bit NE2000 card, IDE hard drive
File: 3.2MB zip file of DOS 3.3, best of 3 gets and puts

FTP 0.65: GET 13.45s, PUT 42.24s
FTP 0.70: GET 10.93s, PUT 340.49s
My FTP: GET 6.87s, PUT 7.92s

Are you all seeing similar results, or do I have something broken?

Also, I've noticed that the WATTCP DNS resolver is completely flaky .. are other people seeing that too?
 
mbbrutman said:
Version 0.70 is slightly faster than 0.65 when receiving, but it seriously broken when sending. ...
Click to expand...
My experience exactly. Very long puts. ASCII is better though.

mbbrutman said:
...
FTP 0.65: GET 13.45s, PUT 42.24s
FTP 0.70: GET 10.93s, PUT 340.49s
My FTP: GET 6.87s, PUT 7.92s
Are you all seeing similar results, or do I have something broken?
Click to expand...
I haven't timed it but that looks about right.

mbbrutman said:
... Also, I've noticed that the WATTCP DNS resolver is completely flaky .. are other people seeing that too?
Click to expand...
What I do notice is that it waits a long time (several seconds) after the transfer before it returns the prompt.
 
An FTP client and TCP suite.

I've been using FTP70 for a while just because it expedient to do so. The drawbacks were not that serious and the most important thing for me was fast ASCII transfers anyway. The binary transfers don't occur in the middle of thinking :) so the extra wait didn't interrupt my thoughts.

With the discussion happening here I went surfing my drives and rediscovered LXFTP. This is part of a suite called LXTCP which is written for the HP200LX palmtop. This FTP client looks like it is based on the same code as WFTP but it works much better. I have just tried it a little just now but it looks good. The text is green on black :), there is little wait (still some though) and the gets and puts appear quicker. It will also take the same configuration file. To me it was a drop in.

Part of the reason I mention this now is that it has source code available. You might want to look at it Mike. (Both Mikes :))

It is available at Sourceforge.
- binaries lxtcp25b.zip 351405
- sources lxtcp25s.zip 531952

Related links:
More network stuff: The HP200LX TCP/IP Suite Home Page
The original maintainer: Rod Whitby's HP200LX Software
 
Can you post some performance numbers since you have it installed already?
 
Ole Juul said:
I know this is drifting OT but it is interesting to consider how well an FTP client hooks up with the server.

I just substituted the WFTP beta (v.65) for my usual v.70 and the result was interesting. Yes, the puts are faster and the gets, although maybe not faster, take almost no time to "complete" or put you back on the command line. A noticeable problem though is that it takes quite a long time to negotiate upon logging in, so it takes a while before one can start using it. Version .70 does not have that problem. This negotiating time is a puzzlement to me. What is it doing? Since Mike C seems to think that v.65 is OK then he is probably using a different server and that is making a difference. I'm using proftpd, what are you using Mike?

BTW, the lack of blue and white is a pleasant upgrade. However it does not recognize the wattcp.cfg file in the environment. Still, waiting for a login or waiting for a download. Six o one, half a dozen of the other. Now I don't know what to do. I really prefer everything to be instant. That's the whole idea of using computers isn't it?
Click to expand...

i use it with a few servers. i use a small freeware FTP server on my windows P4 machine called "Quick 'n Easy FTP server" and sometimes Cerberus which is on my 486.

i also FTP into the rubbermallet.org run by godaddy and my own linux server which both use Pure-FTPd. i have no problems with any of the servers i've mentioned in 0.65. i mainly use the FTP client on my 8088s and 286s.

and mike, i will test out the speed on an 8088 class machine as you asked about. the only one i have with a hard drive (20 MB JVC MFM) is the supersport laptop. i can flip the turbo switch off and see what i get on a 3.2 MB file at 4.77 MHz. i'm at work now but i'll do it when i get home.
 
You must log in or register to reply here.
Back
Top