Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

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

Status
Not open for further replies.

tedsmith

Programmer
Nov 23, 2000
1,762
AU
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?
 
Use the Microsoft Internet transfer control - it's in MSINET.OCX

There is a full description and examples in VBHelp. Check the Help index for Internet transfer control

___________________________________________________________
If you want the best response to a question, please check out FAQ222-2244 first.
'If we're supposed to work in Hex, why have we only got A fingers?'
Drive a Steam Roller
Steam Engine Prints
 
Or the shell's ability to FTP. Some of my example code for that is given about halfway down thread222-1337638. Of the two examples I provide there, I prefer the second. Of course all this assumes that you are running an FTP server service at the other end ...
 
Thanks for the advice.
No other apps. I dont want to run anything except my special application and WindowsXp on any of the computers. I'll try Inet but have seem posts on other forums of troubles sending large files with this.

I wanted to have everything encapsulated in my app.
It is a special data gathering project and there are no humans involoved expect I dump reports to another computer periodically. It is running on a big fibre network with thousands of other workstations with cisco switches everywhere with static IPs supposedly giving maximum security (except that I can see a lot of them in the good old "Workgroup"!
I don't trust their security and I don't want any of them to be able to get to any of my stuff.
(No it's not the FBI!)

I originally though of building in a FTP server into my app but is that too hard?
 
>building in a FTP server into my app but is that too hard?

Not necessarily. But it does rather seem like reinventing the wheel
 
This app runs on a government (supposedly very secure) network and they wont permit any FTP servers or remote desktop stuff running in the background or use of workgroup/ file sharing.
The only thing I am allowed is the one static IP address and port connection per computer on a city wide 3ghz network.

It is already working fine on random 1mb pic's and data between 22 computers thanks to everyone on Tek-Tips help but now I want to send a report log that is about 50mb at 2am each day (even if I ended up using my own method!).
That is why it all has to be within my app.

What I was asking was how do you incorporate FPT completely into the vb6 application at either end. I cant find any examples of how this is done.

I could do it with a straight winsock like I already use to transfer data but I was under the impression that FTP was faster.

 
So would this work using winsock or is there a quicker way?

Read the whole 50mb file (an Access.MDB)into a string or array.
Send the whole string or array.

(Winsock chunks vary in size in a fast computer from 2k to 8k so, unless I introduce a slight delay in the dataarrival. To avoid having to have a huge string, how can I read a file in small enough chunks exactly the same size as what winsock will accept?)

At the dataarrival append the data to the destination file.
On the sendcomplete, send a 2 byte code (chr(1) & Chr(255)) signifying the end.
When the bytestotal received is 1, and the end code is the same, close the file
(the chance of the last chunk of the file being 2 bytes and equal to the code are highly improbable and even if it is, you are at the end anyway.)

I thought FTP was supposed to be quicker than Winsock anyway.
 
>Winsock chunks vary in size in a fast computer from 2k to 8k so, unless I introduce a slight delay in the dataarrival

As you may recall from earlier posts I'm afraid that I've given up discusing this specific issue with you

>I thought FTP was supposed to be quicker than Winsock anyway

This will be because I don't think you actually understand what Winsock is. Try this for an overview:
 
I coded a noddy process using a combination of ftp, batch file, VbScript and Windows scheduled tasks to retrieve a daily log file from a web server and it's been doing its job well for a few years.

It's hardly rocket science nor might it be deemed secure enough for your needs (password is visible within script) but I can post the code if you're interested.
 
Thanks Glasgow,
I have no problem with how the download is managed automatically but I am interested to find the best way of transferring the 50mb file from the server folder to the workstation folder.

I was thrilled to learn the names of the iguanas in the history of Winsock at Wikipedia but it unfortunately did not tell me anything relevant about Winsock that would have any bearing on my question.
 
The point I was addressing your repeated assertion that "FTP was faster [than winsock]". I'd hoped that by pointing you at an article that explained what Winsock was (and which in the very first line says "a technical specification that defines how Windows network software should access network services, especially TCP/IP") you might undestand why this assertion could not be correct.

Bu since you only seem to have picked up on the iguanas' names, I'll try a different explanation

The article I linked to also says in the first paragraph that winsock "defines a standard interface between a Windows TCP/IP client application (such as an FTP client []) and the underlying TCP/IP protocol stack", which I'd have thought made it pretty clear that FTP goes through winsock, and thus could not be faster than winsock- but to illustrate here's a brief overview of the OSI 7 layer model (this isn't the normal generic overviw, it contains a commentary for each layer that is relevant to the most common networking on a Windows machine, namely TCP and UDP via IP over ethernet):

[ul]
Application Layer
Provides services software applications need. Provides the ability for user applications to interact with the network

Presentation Layer
ASCII or EBCDEC data syntax. Makes the type of data transparent to the layers around it. Used to translate date to computer specific format such as byte ordering. It may include compression. It prepares the data, either for the network or the application depending on the direction it is going.

Session Layer
The user's interface to the network. Determines when the session is begun or opened, how long it is used, and when it is closed. Controls the transmission of data during the session. Supports security and name lookup enabling computers to locate each other.

Transport Layer
TCP, UDP. Ensures properly sequenced and error free transmission.

Network Layer
IP network protocol. Routes messages using the best path available.

Data Link Layer
Data transfer method (802x ethernet). Puts data in frames and ensures error free transmission. Also controls the timing of the network transmission. Adds frame type, address, and error control information. IEEE divided this layer into the two following sublayers. [ul]
Logical Link control (LLC)
Maintains the Link between two computers by establishing Service Access Points (SAPs) which are a series of interface points. IEEE 802.2.

Media Access Control (MAC)
Used to coordinate the sending of data between computers. The 802.3, 4, 5, and 12 standards apply to this layer. If you hear someone talking about the MAC address of a network card, they are referring to the hardware address of the card.

[/ul]
Physical Layer
The actual hardware.
[/ul]

(whilst this is an academic model and, in reality, the layers can be somewhat merged, it is still a valid overview of how an application eventually gets traffic onto a network)

In this model winsock is an interface between the Session layer and the Transport layer. And FTP is an application that lives in the Application layer. So, for FTP to work it has to go through winsock; it cannot be faster than winsock

As for your idea of writing an FTP server (whilst possible) how does this get around the "No FTP server" rule you have described for us?


 
I never meant to give the impression that I believed that FTP was faster than winsock. I was ASKING whether it was.

I previously thought FTP was an entirely different way of transmitting data. I have noted in other blogs that people have had trouble sending large files with winsock but not with "FTP" so I am not the only one that was under a misunderstanding.
What I was really asking was "was there a difference? and if so what was the difference?" and you have answered my question thank you.

Regarding a FTP server, I previously wrongly thought you had to have a proprietary separate piece of software that people call a "FTP Server". This is not what I want.
Bring under the misapprehension that FTP was superior, I wanted to incorporate the functionality of FTP into my VB program.

Therefore it would appear that it only remains to use a winsock in the most efficient reliable way to achieve the result and to find the best method of reassembling the data to the large file involved.

This may be a different problem to my original one of previous threads sending much smaller picture files.

Having established that FTP uses WINSOCK anyway, my last question related to what was the best way to handle the sending and reassembly of the file in VB6.

As I explained, I have to do it with only one port.
 
The following is what I use for a similar process discribed in the original posting. I've trimmed it down to just the core parts. I've used this to send to Sun servers and other FTP servers in house and out. It doesn't handle all FTP server types, but should work for your needs.

Code:
'Class - clsFTP.cls
'Add "Microsoft Shell Controls and Automation" to Referances (SHELL32.dll)
Option Explicit
Private myShell As Shell
Private PWord As String
Private UName As String

Public Function Ftp_File(FilePathName As String) As Boolean
    Dim ftpFolder As Shell32.Folder
    Set myShell = New Shell32.Shell
    Set ftpFolder = myShell.NameSpace("ftp://" & UName & ":" & PWord & "@" & IP)
    ftpFolder.CopyHere FilePathName
    DoEvents
End Function

"If I were to wake up with my head sewn to the carpet, I wouldn't be more surprised than I am right now.
 
Yep, we've already provided that method to him back in my first post.
 
I doubt FTP is an answer here because an FTP client is indeed useless without an FTP server at the other end. FTP also always uses two sockets (ports) because it treats one as a control channel and the other as a data channel. The control channel is used for sending commands to the server and returning status to the client.

I'm a bit curious as to whether the "FTP via Shell" technique works in scenarios where there is no desktop present. Examples might include a Windows Service or a simple Scheduled Task that runs when no user is logged on. It's obvious that this technique is limited, since the Shell does not support full FTP operations, e.g. no text mode ("ASCII") transfers, only image ("binary") transfers. Still, this should be sufficient for many needs.
 
Thankyou dilettante, your information about FTP using 2 ports is most illuminating. This is similar to a winsock method originally proposed by strongm and explains a lot.

regarding ousoonerjoe's suggestion, do I need anything running at the receiving end because as I have said all I have is my application and Windows XP?

As I attempted to point out, my current problem is different to my previous thread that was ably answered by strongm and others.
In this problem, I can ping between each computer and I can transfer data using one winsock at each end without any problems.
However I cannot share any folders in either computer nor use copyfiles or workgroups because only the specific ipaddress and the one port is allowed through a complicated arrangement of firewalls and Cisco switches outside of my control. (Our government fibre optic network).

The question is what is the best way of automatically sending a 50mb report file once a week in the small hours?

It is not often relatively minor programmers like me get the opportunity to mix in such exalted circles so I dont want to make a mess of this one.
The system is now up and running minus the automatic report.
I suspect I only got the job because they didn't want to broadcast what they were doing by involving a big firm and they told me that no government employed programmer knew how to do it!
 
>regarding ousoonerjoe's suggestion, do I need anything running

Yes. Since ousoonerjoe's suggestion is exactly the same solution as the example I pointed you to in my first post in this thread (in fact it's just my code repackaged slightly) it has the same requirements that I pointed out in that post: an FTP Server at the other end.
 
There is a simple solution, every computer has at least one share named C$, this is a hidden share for the C drive. Likewise there will be hidden shares for other drives if the computer has multiple drives.
You can simply copy the file from the server using \\server\C$\folder\filename.ext as long as you know the administrator or equivalent password for the server - now I understand that getting the password may be another problem.
I use above method at another government institution (heard of NASA?) with the same security overkill BS.
 
yep, StrongM that was the post i referenced for the ftp code shown.

Remember, XP Pro (not sure about other versions) comes with an FTP service. Just go to Add/Remove Windows Components in Control Panel and configure it after install.

"If I were to wake up with my head sewn to the carpet, I wouldn't be more surprised than I am right now.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top