File send app - md5 checksum different when load is put on server.

I have written a application using Winsocks and TCP which sends a file across the network.

After the transfer is complete I check the file integrity using a MD5 checksum. Here are the results.

No CPU load on server : No CPU load on client - Fine (md5 checksums match)
No CPU load on server : CPU load on client - Fine (md5 checksums match)
CPU load on server : No CPU load on client - DIFFERENT checksum on received file on every transfer!

So the problem is when the server (host of the file) has 98-99% usage the file isnt sent correctly. The weired thing is even though the md5 hash is different the byte count on both the files is the same.

BTW, im using the WinRar benchmark to put load on the CPUS. Its using a LAN 10/100Mb connection.

Can anyone explain this? Im really not sure how I can fix this.

Thanks

> Can anyone explain this?
Bugs in your code - pure and simple.

For example, if you assume that a buffer is always filled, then you might be tempted to write out the size of the buffer (and not the number of bytes received). So naturally in this case, you'd always end up with the correct byte count.

od -Ax -t x1z file | more
Run this side-by-side on the original and copy of the file, and look for actual differences.
My guess is the corrupted copy will see blocks of repeated previous data through your sloppy buffer management.

the most likely source is when reading the file, you ask for X bytes and assume you get X bytes, when in fact you are probably getting <X bytes at least occasionally. It only shows up under I/O load, i.e. when other applications are also accessing the file system.

Not sure if you use fread() or ReadFile(), but its the same issue with either one.
With ReadFile, make sure you use the value returned and don't assume it read everything you requested, it may in fact return 0. For fread() be sure to check the count of full items read.

I suppose it could also be an issue with your protocol, but if you are getting the right number of bytes across the netowrk, then that is probably not it.

Thanks abachler, on reviewing the file handling code, there was a potential bug but that wasn't causing the issue in this case.

The problem Salem said (which is obvious now). Assuming the buffer was always full.

So I have implemented the following code in the client. Seems dodgy is there a better way to do this?

Code:

---


while (br = recv(remoteConnection->socketfd, (char*) &nsp->mp, sizeof *nsp, MSG_PEEK) < sizeof *nsp){}
                   
br = recv(remoteConnection->socketfd, (char*) &nsp->mp, sizeof *nsp, NULL);

---

It dosnt seem good to be infinite looping until a full buffer (which is a packet for me) is received.

Also is using MSG_PEEK a good idea? Is there any way to get the size of the msg stack without actually reading it?

Why would you need to loop until the buffer is full?

Just take whatever the network lets you have, and save it in your file.

Code:

---

while ( (br=recv( sock, buff, sizeof buff, 0 )) > 0 ) {
    wr = write( buff, 1, br, outfd );
    if ( wr != br ) { panic(); }
}

---

Quote:

---

Originally Posted by Salem

Code:

---

while ( (br=recv( sock, buff, sizeof buff, 0 )) > 0 ) {
    wr = write( buff, 1, br, outfd );
    if ( wr != br ) { panic(); }
}

---

---

need to add something in there to make sure you got it all, since the socket may return 0 even before the file is finished. Personally I would add some flow control into the stream.