Sockets and File Transfer and Corruption Problems
MikeA
trying to transfer a file. I've written the client server programs and
everything works but there seems to be one problem and I can't figure out
what is wrong.
When the file is transferred it is corrupted. I have a test program that
tries to send a 75 megabyte zip file. All of this is tested in my LAN
environment (even running both programs client/server apps on my on my own
computer). I have compared the files and noticed that what is happening is
this: If I send chunks of data of say 1024 bytes then it successfully sends
around 140K of data then 1024 bytes of data after that is nothing but zeros
then data is good again for a random amount of bytes in the file then
another 1024 bytes of data is nothing but zeros. Sometimes it is less than
1024 bytes but there is a chunk of zeros where there should not be.
I have tried to troubleshoot this and right before I load the socket buffer
with data that I read from the file (to be transferred) I check and there
are no zeros being loaded into the buffer. Then on the server side when the
data arrives I check and every so often there are a bunch of zeros. It's as
if the data is getting corrupted along with way but I thought TCP/IP is
supposed to do all the error checking and resending for me.
I have checked the client side and it is not ever loading the socket buffer
with anywhere near 1000 zeros anywhere in the file. But, it's like random
places throughout the received file have zeros in them. The code on the
client side puts data in the buffer of 1K chunks and then sends data and I
check for errors and when I get an error I stop sending data and wait for
the Mabry send event to fire so that the mabry socket is ready to accept
more data. When the file transfer finishes the file size does match - it's
just it has these zeroed out chunks of data of 1024 bytes (which is the size
I'm sending in a loop). I've tried sending 4K chunks instead of 1K as well
as 2K, 5K, etc. and the file always gets corrupted with blocks of zero every
so often throughout the file.
If I send the file a second time to the server so that the server has say
file1.zip which is the first file send then I send the file again and call
that file2.zip on the server I then compare file1.zip to file2.zip and those
don't match either and there are random chunks of zeros through both files
otherwise the files match. It's just every so often there is a chunk of
zeros that arrives on the server side. One other thing I noticed and that
is on the server side when the receive event fires and data arrives it could
be 100 or 200 bytes of good data or more followed by a bunch of zeros.
This is driving me crazy - it's almost as if the TCP/IP is not doing the
error checking which I would think it should. I can't figure out what is
wrong.
Please help.
Thanks,
Farooque Khan
causing the problem. TCP is a stream protocol, unlike UDP, so don't expect
chunks of data to arrive in same sizes as sent. When the recieve event
fires, figure out how much data has arrived and store only that much of
data. Don't expect TCP to hand you over the data in same chunk sizes as your
buffer or the size of the sender buffer. For example, if you send 1024 bytes
of data, your recieve event may fire once with 1024 bytes, or 2/3/4... times
with varying number of bytes.
--
-Farooque
"MikeA" <app...@appellsoftware.com> wrote in message
news:e7fiRN0h...@TK2MSFTNGP04.phx.gbl...
MikeA
For some reason when I load the winsock buffer with data and send it and I
check it with a sniffer it is not sending out what I'm loading into the
buffer. I don't know if it is a problem with Visual FoxPro, the socket or
how it is loading the socket with the data but it's not working then if I
try again it will work and then it won't work. Various chunks of data are
getting corrupted at the "sending side" from the time when I load the socket
to when the socket sends the data. I checked this with a sniffer but I'm
stumped as to what the problem is.
Thanks for any help,
Mike
"Farooque Khan" <farooqu...@info-spectrum-removenospam.com> wrote in
message news:u8fDwb7h...@TK2MSFTNGP04.phx.gbl...