• Please review our updated Terms and Rules here

Features for an FTP client

...
BTW, you had a 3.2MB file that you were transferring in about 3 seconds. (I think that was the receive rate.) At that speed you are doing 1MB/sec, which is just about line speed for a 10MB/sec connection. You are not going to get any faster with a P133 no matter what you used because we are burning a hole in the 10MB/sec card.
Thats awsome. I think I'm going to like this one!

For people who have slower machines that are not maxing out the Ethernet card - you should notice that my FTP is faster relative to the other FTP clients. I'm not using as much CPU which makes much more of a difference on something like a 80286 or 8086.
I don't have an older machine set up at the moment, but I'm looking forward to seeing what Mike Chambers comes up with here. (If he isn't busy starting another project :p )

EDIT: oops! I didn't renew the sceen and so missed MC's post.
 
The usual way ...

ftp servername < ftpcmds.txt​

Put the userid, password and commands in ftpcmds.txt as you would type them in and it should work.

That works, and response is snappy, but it exits the program. I could do some handy batchfiles with % to work with that, but is there an easy way to avoid exiting?

Here is what happpened:
Code:
O:\ $FTP-0119.EXE 192.168.1.101 < sco.cmd

Ftp by M Brutman (mbbrutman@yahoo.com)
  Version: Jan 18 2009

FTP server resolved in 0.00 seconds

Opening control connection to 192.168.1.101:21 with local port 2079
Connected

220 ProFTPD 1.3.0 Server (SCO) [::ffff:192.168.1.101]
Userid: ole
331 Password required for ole.
Password: ********
230 User ole logged in.
--> cd /home/ole/DOWN
250 CWD command successful
--> pwd
257 "/home/ole/DOWN" is current directory.
-->
-->
Tcp: Sent 13 Rcvd 9 Retrans 0 Seq/Ack errs 0 Dropped 0
Packets: Sent: 14 Rcvd: 10 Dropped: 0 LowFreeBufCount: 19

Please send comments and bug reports to mbbrutman@yahoo.com

O:\ $
PS: There was no EOF marker, if it makes any difference.
 
Can you post the script (except the password line) so I can recreate it here?


Mike
 
Sorry - that seems like it is working as designed. The end of the file was hit, and the program ended.

Were you just trying to automate the login sequence and then use it interactively? If so, I'll provide another way to do that, probably by a configuration file or environment variables.


Mike
 
Hi Mike,

I like the numbers. The get and put times for the Zenith are just a little faster than my XT, which makes sense given the better clock speed. My XT is only 4.77Mhz, but I have a 3C503 on board so that helps it.

The 80286 numbers look good too.

I think I'm done for a bit .. share and enjoy, and if you want help/advice on server linking I'm around. (Although you've have the IRC server well in hand up to this point ...)
 
Sorry - that seems like it is working as designed. The end of the file was hit, and the program ended.
That's what I figured.
Were you just trying to automate the login sequence and then use it interactively?
Yes, I like the idea of just typing a short command, say the name of the machine to which I want to connect, and landing in the right directories ready for quick put or get. Thats how I was doing it before.

If so, I'll provide another way to do that, probably by a configuration file or environment variables.
Mike
You probably know, but WFTP/LXFTP does it like this: ftp -f file.txt
A way to automate login and not exit would be nice but not essential. Like I said, batchfiles can take over from here. The thing is that now, unless you type in the whole thing, it has to log in every time you want to do something with it. However, its pretty snappy, so there might not be any appreciable performance hit.

Cheers,
Ole
 
For years, I've been using NCSA FTP for file transfers to/from my development 5160. Here are get and put times using an Intel Etherexpress card (using IRQ/DMA/port to transfer data) to/from a CF flash card running on an ADP50 IDE controller (RAM disk in EMS is slower!) for a 258K file:

GET: 15.3 KB/s
PUT: 25.9 KB/s

Now, using mTCP's FTP:

GET: 13.5 KB/s
PUT: 22.5 KB/s

A hair slower, but the advantages (clean implementation, small .exe size) outweigh the 2KB/s speed difference. Excellent work!

Add batch capabilities (ie. the ability to read commands from a file) and I can use mFTP for my weekly backups!
 
Are you talking about the FTP server built into NCSA Telnet, or an FTP client from them? I've always tested against the FTP server built into NCSA Telnet have have been significantly faster, so I don't understand your results.

Can you point me to the code you are running so I can try it here?
 
I don't like Trixter calling my code slow, even if just by a hair. ;-0 So I did a little tuning of buffer sizes and other parameters. The receive performance about 15% faster now on my NEC V20 machine. The send performance is about the same.

If you get the same bump that I get, then the receive speeds will be about the same as what you saw with NCSA FTP. I know that they were using a slightly bigger file buffer, so I one-upped them. ;-)

Sends are problematic - I haven't been able to do anything simple to make them faster. The problem with sends (compared to receives) is that you have to hold onto outgoing packets and check to see if they need to be retransmitted.

On a related note - my PCjr (the NEC V20 machine) is getting 24KB/sec for receives and 19.5KB/sec for sends. My machine is at a severe disadvantage to yours - No DMA, a parallel port Ethernet adapter, and a parallel port to SCSI adapter for the hard drive. The only thing I have going for me is that the NEV V20 is 5 to 10% faster than your 8088. So why is your receive time so bad? Even before my latest performance changes this machine was receiving far faster than yours, and it shouldn't be.
 
Trixter: For years, I've been using NCSA FTP for file transfers ...

mbbrutman: Are you talking about the FTP server built into NCSA Telnet, or an FTP client from them?

You've left us hanging here. I'm dying to find the answer! :)
My guess is you're running the NCSA server and connecting with whatever client on the "outside" machine, but since we've been discussing clients I thought that there might be a NCSA client out there that I didn't know about.
 
<Resurrecting a dead thread!>

I picked up this project again after a little hiatus. MPUT is working now, but it's not well tested - I have no idea what will happen if you press Ctrl-C in the middle to cancel it. MGet is coming next, and then I'll fix the usability issues that people have reported.

Does anybody ever use the 'prompt' mode to OK each and every file transfer? It seems cumbersome .. I've personally never used it and get annoyed if I have it on by accident.


And in other news, I'm writing a BASIC interpreter but don't tell anybody at work - I'm telling them it's a simple and easy to use scripting language. ;-)
 
I don't feel that any kind of y/n/a prompting is appropiate for any software except before deleting files, and even then I like to have a -f switch.
 
You've left us hanging here. I'm dying to find the answer! :)
My guess is you're running the NCSA server and connecting with whatever client on the "outside" machine, but since we've been discussing clients I thought that there might be a NCSA client out there that I didn't know about.

I was using FTPBIN.EXE (the ftp client that comes with NCSA) as a client to do transfers to/from my linux server.

Mike: I do completely believe that the speed difference is due to your PCjr having the NEC. The V20 has a bigger prefetch queue (don't laugh, 2 bytes makes a difference!) and MUL/DIV is much faster due to dedicated microcode. All of this can definitely add up in tight loops.
 
Does anybody ever use the 'prompt' mode to OK each and every file transfer? It seems cumbersome .. I've personally never used it and get annoyed if I have it on by accident.

I had to use dialup for years and years. Now that I have something faster, I can imagine doing a MGET with a prompt. That case being I want most of a subdir but the file names don't fit into a nice wildcard situation. With the broadband, unless the files were ISO images at 1200MB apiece, I would likely just download the entire subdir with no prompt and delete the ones I didn't really want. Translation: indeed, not very likely to be used in either direction. If you are updating a website, you frequently would have an entire directory tree and would want to upload everything including the structure (all the subdirs under the main one). Again, no use or interest in a prompt.
 
I posted the latest version on the 15th. If you need MGET/MPUT support you definitely want that one.

My current private copy adds the ability to pause the output from directory listings, which is really nice for when you get a 500 line listing that scrolls past your 25 line screen. The feature can be turned off. I'm also working on 'scrubbing' the code for speed, size, and bugs.

I think that I've accomplished everything that I set out to do initially:

  • File transfers: Get and Put with BIN and ASCII modes
  • Multiple file Get and Put with MGet and MPut commands
  • All three transfer modes: Classic (where the FTP server connects back on a default port), Port (where your client tells the FTP server how to make data connections) and Passive (where your client makes data connections to the server). Most people will use Port or Passive - Classic is required for dealing with ancient FTP servers like NCSA Telnet/FTP or ancient Unix boxes.
  • Good file transfer performance. (I added two environment variables for adjusting buffer sizes that help tailor memory utilization and performance for your specific needs.)
  • Shell to DOS support for executing local commands not implemented in the FTP client.
  • 'Quote' command support for passing commands directly to the remote server.
  • Robust Ctrl-Break handling .. being able to abort a transfer reliably and get control at the command line is a serious usability requirement. I think I got it right. You can Ctrl-Break almost anywhere.
  • Relatively small size and memory requirements. The executable is under 90KB total, including the TCP/IP stack. Run-time requirements range from 140 to 180K free.
  • Scripting support - accepts input from STDIN, and can push output to STDOUT.

So before I button this up and move on to something else, what did I miss that you'd like to see?


Mike
 
I looked for a link to download but could not found, I'm a bit lost where can i find your FTP client?
Will it work on 8086?
Do i only have to load a packetdriver no protocol drivers?
Will the application automatic set an ip-adress for card if i connect it to a router with DHCP?

****Edit found download***** Very informative site, thanks!
Let see if i can get this app working, you wanted features?
I would like to be able to ping other computers in network, maybe already possible?

What protocol is used for microsoft shares IPX or Netbios? Would it be possible to list IP and IPX/Sharename for a computer or most IPX be loaded?

Feature: I always wanted a way to scan a domain 192.168.0.2-254 for shares, FTP servers, NFS and why not HTTP servers on the computers. OK i can see this would be a little to much but, would it be possible to scan the domain for FTP servers?

A connection information command would be nice, listing own IP, Gateway and DNS (have no idea if Gateway and DNS is part of TCP-IP? Maybe they are extensions?).


JT
 
Last edited:
All of the information on the apps is available here or at the pages rooted here:


All you need to load is the packet driver. The programs do the rest. (So you do not need NTCPDRV.EXE or any other TSRs.) All of the code works well on 8088s, 8086s and newer or better processors.

The four pieces of code that you will find are:

  • DHCP client for getting an address on your network
  • IRCjr - my IRC client
  • FTP client for doing file transfers
  • Netcat for raw data transfers from machine to machine

The protocol used is TCP/IP. There is no IPX or NetBIOS. There is no filesharing support using drive letters or anything like that, although that might happen one day.

If you use the DHCP client it will tell you the settings it got from your router. The settings are also stored in the 'mtcp' configuration file, which you setup using an environment variable. If you do static configuration then you probably know what everything is already.


Mike
 
@JT64:
You can do ping, traceroute, and more with the utilities that come with many wattcp packages. I don't have a link at the moment but I'll send you the binaries if you like. Also, you can scan ports and a whole whack of other stuff with NTOOL for DOS which can be gotten here. It's amazing what you can find on the VCF eh? :)
 
If you want to see the split screen mode I'm talking about, try my IRC client. Basically the top 21 lines of the screen are status and the bottom 3 lines are for user input.

The advantage of split screen is that I can very tightly control the screen updates, and do it using very fast memory operations. It also allows me to implement a backscroll buffer very easily.

No mouse is required. (Or supported, or needed!)



Well, that's kind of standard for FTP. At least userid and password could be easily scripted by providing them in a configuration file or as environment variables. As for the rest of it, if I don't do split-screen the FTP session can probably be scripted by redirecting STDIN. (Which is why I'm still debating doing the split-screen thing.)



It's my own TCP/IP with it's own configuration file. Configuration is minimal, as it supports DHCP.



What don't you like about your current program? Does WFTP have DNS resolution in it? Does it support mput and mget?


Mike

Hello Mike will your DHCP work with a modern router "DI-624+" and a PCXT my XT use a DE220 NIC.

Packetdriver used is D22XPD.COM loads ok.

I've tried connect but i only get 1 packet sent 12 received.

I think maybe the router DHCP use 192.168.1.x not 192.168.0.x could this cause problem?

It could be problem with my NIC since i can not get networksharing with Netbeui and IPX on my XP machine to work with the PC_XT

I probably need to a packet scanner.

JT
 
Back
Top