What is the best way of integrating FTP in my app?

[tedsmith]

I would like to be able to automatically download a 40mb file every week from a dedicated server to a client (at 2am in the morning!)

The server is exclusively for this project and merely collects data and dumps it once a week but it is on a very large private network not connected to the internet.

I have a winsock connection through to this server OK to examine the data but I would prefer not to use Workgroup, filecopy or anything that might let others see the computer without my software being installed.

There are no humans awake at the time of transfer to enter passwords etc.

Is FTP the best way or is there a better way?

I have seen many references in Google to third party FTP.DLLS but I would like to avoid these if possible unless there is a particularly good one someone could recommend.

I'm OK with the automatic timing bit but, if FTP is the best way, what is the code I would have to use for the FTP part of it and optionally, is there a sort of automatic unattended password I could setup?

 

[strongm]

>Remember, XP Pro (not sure about other versions) comes with an FTP service.

Sure. But so what? The point we raised early in the thread was that for FTP to work an FTP Server was required at one end. And Ted then said he wasn't allowed to run an FTP server, whether it be Microsoft's included one, or any 3rd party version. So the availability (or not) of XP Pro's FTP Service is moot.

>every computer has at least one share named C$,

No, actually it doesn't. Not in a properly secured environment

>Likewise there will be hidden shares for other drives if the computer has multiple drives

Nope. See above

>as long as you know the administrator or equivalent password for the server - now I understand that getting the password may be another problem

Now there's a fairly significant understatement. Are you seriously suggesting that a genuinely secure environment happily hands out passwords to accounts with full admin privileges?

>security overkill

Well, clearly not actually.

 

[tedsmith]

Well, actually I am the only person who knows the administrator passwords of the 2 computers! So I shall try this new suggested method as soon as I get back from holidays.
Unbelievably thay have provided me with a 28k dialup connection to the part of the network that contains the sending computer (server) so I can use Windows remote desktop from my home to fully control that computer (and see a host of other peoples folders there as well! If I were a hacker I would be in heaven.)

The receiving computer(client) is however on another network connected via firewalls in a different part of the city and only the ipaddress and port is allowed which means I can ping it OK from the sending computer under control from my home.
I cant see any of it's folders or share them to the server and when I am at the client, I cant see or share any server folders so I suspect \\server\C$\folder\filename.ext might not work but I'll give it a try.

By the way, the weather is incredible up here on the Great Barrier Reef. Complete blue skies mild balmy breezes brilliant blue water - you should all try it!)

 

[dilettante]

Hidden share, visible share, none of it matters if you don't have the ports open for Windows Networking.

No matter what you'll have to have two cooperating programs, one at each end, if you really need to push this file across a single TCP connection on some arbitrary port. Since that's pretty clear at this point I don't see much else we can contribute.

 

[strongm]

Quite so

 

[tedsmith]

dilettante, could you enlighten me on
<if you don't have the ports open for Windows Networking.

Are there specific ports used for this or are they variable?

If I got them to just open these ports, would it automatically let others also see the computer on a workgroup?

 

[dilettante]

It is almost a certainty that they won't want to open the necessary ports. In its full generality Windows Networking transports lots of functionality, file and printer sharing being the tip of the iceberg.

For just sharing you'd probably need TCP ports 139 and 445, and UDP ports 137 and 138:

File and Printer Sharing Does Not Work

 

[strongm]

http://support.microsoft.com/kb/832017

>If I got them to just open these ports, would it automatically let others also see the computer on a workgroup?

Generally, yes.

 

[tedsmith]

Thank you all.

>No matter what you'll have to have two cooperating programs, one at each end,

Of course that is what I intended from the start, only that the only program at either end is one single application that only I provide. It also has to continuously fulfill the functions it is already doing AS WELL as send a large report each night.

What I didn't want to use was an "FTP server" written by anyone else.

Now that you have cleared up in my mind "what is FTP?", it now only remains to decide what is the best code to incorporate in my single applications at both ends to send and receive the large report on one port at each end.

Probably what I am already doing for the smaller 1mb pictures in my previous threads is the best anyway unless there is another way.

One aspect that clouded my original speed measurements was I was using a cheap 100mhz switch and one computer was a 1ghz, the other 100mhz. The transfer was 20 times faster when I ditched the switch.

 

[dilettante]

You need to be careful when mixing and matching network components. I've found that some NICs do not properly auto-negotiate to speed/duplex settings that are compatible with a given switch.

The result seems to vary from not working at all to working with many collisions and poor data transfer rates.

Generally you can compensate by explicitly setting an appropriate value for the NIC.

 

[dilettante]

Sorry to gravedig this old thread, but another option might have been to use an HTTP Server control in your program at one end and any of several methods of doing HTTP downloads.

There are several of these around commercially and a few open source ones written in VB6. Most of the latter don't have authentication built in though this is easily added. Several of the commercial ones offer SSL for transfers over the Internet.

I recently tossed one together myself because I didn't like most of the code I saw out there. It's basic but it does the job and an embeddable HTTP server is a useful thing to have in your toolbox. It could be optimized internally but I just did a test and a 20MB file downloaded in just a few seconds here. It was written in a very straight forward manner with no attempt at smart buffer management or anything.

Few support full HTTP uploads via POST or for that matter the PUT method, let alone any level of WebDAV. Adding PUT or full featured POST (with files) shouldn't be too bad with proper precautions (authentication), giving you bidirectional transfers over a single open TCP port number.


The advantage of a generic approach of this kind is that you'll probably find lots of uses for it. This saves time over constructing ad hoc file transfer logic for different projects.