On Feb 12, 2008 4:41 PM, <
fouldragon@aol.com> wrote:
> 1- If I left it for a while instead of a few panicked seconds, it
> would timeout and drop the connection, ending FTP and moving on to the
> next file. This would result in a lost file.
Default number of TCP retries is 6 in exponential backoff and should
time out after a few minutes. That's how long you have to
resynchronize your TCP stream before the other end destroys the
session...
> 2- It might hiccup, corrupting the file. Equally bad if not worse.
> I'm assuming that packet checksums and serial numbers (flashing back to
> CSE420 :) ) make this unlikely.
TCP ensures that data is not corrupted, so if the program was written
properly, all packets should be sent and received correctly, but who
knows if the app you are using has signaling issues ;-/
> If I check the recipient side and it's uploaded a file of the correct
> size and date, can I assume that it's also uploaded an intact file?
> (the script forces binary mode FTP, so it's unlikely we'd have problems
> with CR-LF conversion)
No. You should be using md5sum or some other hashing algorithm to
verify things like this...
> Since the script takes 8-12 hours to run (and produces, among its
> output, a 5.6G .tar.gz file and several in excess of 1G), I'd prefer to
> not have to either re-run the script or download the results to ensure
> correct function.
Agreed :-) I just glanced over your email, but you do know about screen right?
--
Kristian Erik Hermansen
"Know something about everything and everything about something."
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)