Thread: FTP programming in C

There are libraries you can link to that will give you FTP capability. Keep in mind that the FTP protocol exchanges username and password in the clear (as is all the data being transmitted), so be sure to use a highly restricted account.

It is six of one, half dozen of another. If you want absolute control of the timing, embed it in your program. If you can be positive that the time scheduled for the file transfer will never coincide with the time that the files are being created/modified, then the scheduler works fine. You still have to write the code either way (unless you are going to script the FTP, which is fine on an intranet with a dumbed down account).

Say you do your file processing at 10 AM and it is expected to last 30 minutes. Then you do your upload at 10 PM and it is expected to take 5 minutes. Should never be any chance of overlap, right? That may be true 99.9% of the time, but weird things happen and occasionally you may see overlap. You can, of course, use signal files, etc. to create some sort of flow control (research IPC (inter process communication) for more about those sorts of headaches), but all that goes away if you have a single program that does it all. Of course, that won't save you if that single program gets hung (believe me, it will happen!) and is still 'running' the next time the task is scheduled to run. You can easily wind up with 80-90% of your code just being there to handle wacko error conditions that happen once a year, but that is what being a paid professional is all about. I would make the unified program and use some sort of OpenSSL library for encrypted communication (being the paranoid sort), coupled with either a database or attempts at file signaling to detect errors and/or concurrent running. A lot depends on how much learning curve you have to go through and how time sensitive the project is. As you say you are a newbie, I would start out with a simple FTP script can call it via system() (system blocks until the program it calls returns) and a simple file (maybe put the process PID and start time in the file, delete it when complete) for dealing with concurency. If it turns out that is good enough, move on to the next project. If not, at least something is working while you bore through the learning curve to try and get your FTP code working.

Do the FTP script thing, it is quite painless. The use of a file for 'locking' does have problems (research 'race conditions' if you are bored), but they are typically on the milisecond or less timescale (though, as a hacker, you can stretch that interval out to a few seconds or longer with some clever tricks), so if you are going to run once a day that should not be any potential problem. Just delete the file when your program has completed cleanly and check for the presense of the file first-thing on startup and exit if it see it. Why I suggest putting in the PID and the start time is so that when you go to diagnose the error you can find out if the program is still running or not. Note that you will have to manually delete that file if your program ever crashes! I often have my programs email me a status report when they are finished so I have some clew on what the problems are. The problem with that is you develop a reflex of just deleting the emails, then forget if you recieved it. Ultimately, though, there is only so much automation you can do, at some point a human has to evaluate if the program output is correct.