teemartin
asked on
FTP packet tracing
Normally we use use data compression (zip) before FTP'ing a file. This allows us to check for data integrity
simply by uncompressing. Failure to uncompress implies data corruption.
However, we now need to FTP to a destination where data compression is not wanted. We are executing
the FTP from SCO UNIX to a Window 2000 PC. We are looking for a way to test data integrity without zipping
the data prior to FTP'ing. From the FTP prompt, if I type the word 'trace' it toggles between 'Packet
tracing on' and 'Packet tracing off'. The manual seems to imply that packet tracing is not implemented
at this time. Does anyone know if there is a way to use packet tracing, or another way to verify that data corruption doesn't occur during the FTP process?
simply by uncompressing. Failure to uncompress implies data corruption.
However, we now need to FTP to a destination where data compression is not wanted. We are executing
the FTP from SCO UNIX to a Window 2000 PC. We are looking for a way to test data integrity without zipping
the data prior to FTP'ing. From the FTP prompt, if I type the word 'trace' it toggles between 'Packet
tracing on' and 'Packet tracing off'. The manual seems to imply that packet tracing is not implemented
at this time. Does anyone know if there is a way to use packet tracing, or another way to verify that data corruption doesn't occur during the FTP process?
Packet tracing per se is not going to provide a data integrity check unless you do it manually. I would have thought that the standard TCP packet checksumming would provide a fairly good check.
When you say that the data receivers don't "want" compression does this imply that they do not want any post-transfer processing at all?
If they were not averse to post transfer processing and you wanted some form of verification presumably you could write an UNIX based program to "wrap" the data to be transferred into a file containing a checksum on the data and a Windows based program to "unwrap" the data and, at the same time check the "unwrapped" data against the checksum contained in the file.
Cheers - Gavin
When you say that the data receivers don't "want" compression does this imply that they do not want any post-transfer processing at all?
If they were not averse to post transfer processing and you wanted some form of verification presumably you could write an UNIX based program to "wrap" the data to be transferred into a file containing a checksum on the data and a Windows based program to "unwrap" the data and, at the same time check the "unwrapped" data against the checksum contained in the file.
Cheers - Gavin
data integrity is built into tcp...if a packet is lost or corrupted it is resent...so extra measures aren't really needed...but if you want to verify data integrity after transmission, then i would create an md5 hash before and after the upload and compare the two.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for the input, I'd give you all 25 points if I knew how. SteveJ's will work for us because we can check file size on both sides thru FTP commands. I'm sure the other solutions would work as well, if I had the time to look into algorithms.
If you want to do simple error checking, you can write a program, or find one, to do file checksums.
This is a free one I found:
http://www.geocities.com/SiliconValley/Heights/3222/ffv/