Archived

This topic is now archived and is closed to further replies.

HJB417

Winsock 1.1: developing/refining a File transfering function. Need help with mine

Recommended Posts

Hi, I need help with my file transfer function. In tests, the sender sends the file but the receiver never seems to get the complete file, only 99.9% of the file. [only once did it the receive the full file]. Can someone tell me what is wrong with my function. On the receivers end, I have it go in a while loop containing the recv() until recv() == 0 and for the sender, I have it in a while loop until it sends all of the data. The test file is 4.9MB. The laptop NIC is USB. When I send it to the desktop from the laptop, it almost always sends full packets but when I send the file from the desktop to the laptop, the laptop receives a lot of packets which are smaller than the programs packet buffer size. I use 8192 bytes as the buffer size. Also, the laptop is win98 and the desktop is win2k. Here are the results: amount read from file: total amount of bytes read from the file amount sent: total amount of bytes sent using send() packet errors detected: number of send()s that sent less than the maximum buffer size actual time vs ETA: actual number of packets sent | estimation of how many packets will be sent Here is the stripped code (I took out the error handling functions and there are data members and functions defined outside of sendfile(), receivefile(). ) http://templar-archives.dyndns.org/question11.cpp ============================================= Transfer Test 1: results from sender (laptop) amount read from file: 4920282 amount sent: 4920282 packet errors detected: 1 actual time vs ETA: 600 | 601 results from receiver (desktop) amount read from packets: 4918833 amount written to file: 4918833 packet errors detected: 9 actual time vs ETA: 604 | 601 ============================================== Transfer Test 2: results from sender (desktop) amount read from file: 4920282 amount sent: 4920282 packet errors detected: 1 actual time vs ETA: 600 | 601 results from receiver (laptop) amount read from packets: 4920282 amount written to file: 4920282 packet errors detected: 908 actual time vs ETA: 1048 | 601 ============================================== Transfer Test 3: results from sender (laptop) amount read from file: 4920282 amount sent: 4920282 packet errors detected: 1 actual time vs ETA: 600 | 601 results from receiver (desktop) amount read from packets: 4918833 amount written to file: 4918833 packet errors detected: 4 actual time vs ETA: 602 | 601 ============================================== Transfer Test 4: results from sender (desktop) amount read from file: 4920282 amount sent: 4920282 packet errors detected: 1 actual time vs ETA: 600 | 601 results from sender (laptop) amount read from packets: 4918833 amount written to file: 4918833 packet errors detected: 883 actual time vs ETA: 1034 | 601 -------------------------- One problem with the programmer's mentality is insecurity. This goes deep. An insulting college litany says that failed mathematicians become computer programmers. They are also ridiculed for being nerdy losers, for being too fat or too skinny, and for having few social skills. Most programmers can be spotted easily in a crowd. Nobody really wants to hang out with them. Put thousands of these people in one company and if you can get them to work, you become a billionaire. -John C. Dvorak Edited by - HJB417 on January 16, 2002 3:03:19 AM Edited by - HJB417 on January 16, 2002 3:05:39 AM

Share this post


Link to post
Share on other sites
Alright, here''s my theory.

The reason the transfer never appears to go to completion is because the receiver does indeed receive the entire file, but in an unexpected order.

According to your code, the sender will fly through several send() calls which transfer the file name and length. These are very specific sizes sender-side, but the receiver has no idea what the size of the incoming data will be. The file name will (probably) always be less than your 8000+ char buffer, and thus the receiver goes ahead and crams the size data and probably chunks of file data into the buffer on that one recv(). This occurs because you default to a standard buffer size instead of the expected size of the data. For example, you should really use sizeof(long) instead of FILE_TRANSFER_BUFFER_SIZE for file size to ensure that you get *exactly* what you are expecting. This may also explain your "last cell seems to always have some weird data" comment after receiving the file name. I would check to see if the number the receiving side believes is the size is equal to the actual length; if they are not equal, you know what your problem is.

Share this post


Link to post
Share on other sites
quote:
Original post by johnnie2
Alright, here''s my theory.

The reason the transfer never appears to go to completion is because the receiver does indeed receive the entire file, but in an unexpected order.

According to your code, the sender will fly through several send() calls which transfer the file name and length. These are very specific sizes sender-side, but the receiver has no idea what the size of the incoming data will be. The file name will (probably) always be less than your 8000+ char buffer, and thus the receiver goes ahead and crams the size data and probably chunks of file data into the buffer on that one recv(). This occurs because you default to a standard buffer size instead of the expected size of the data. For example, you should really use sizeof(long) instead of FILE_TRANSFER_BUFFER_SIZE for file size to ensure that you get *exactly* what you are expecting. This may also explain your "last cell seems to always have some weird data" comment after receiving the file name. I would check to see if the number the receiving side believes is the size is equal to the actual length; if they are not equal, you know what your problem is.


You are indeed correct, a guy in a newsgroup told me: "That does not matter. When you call send() in blocking more, it DOES NOT mean that it only returns when the buffer has been sent out the NIC, it simply means it has been copied to a internal buffer and will be sent out soon. So, your first two calls to send() will likely be combined and sent out as one message" and he suggested that I place a special character after I send() the filename and the file_size so I can know where the file transfer starts which is what I''m gonna try to do now.

Good thinking though johnnie2, sending the exact size of the file_size and the filename is a good idea too, instead of using FILE_TRANSFER_BUFFER_SIZE.


--------------------------
One problem with the programmer''''s mentality is insecurity. This goes deep. An insulting college litany says that failed mathematicians become computer programmers. They are also ridiculed for being nerdy losers, for being too fat or too skinny, and for having few social skills. Most programmers can be spotted easily in a crowd. Nobody really wants to hang out with them. Put thousands of these people in one company and if you can get them to work, you become a billionaire. -John C. Dvorak

Share this post


Link to post
Share on other sites
Technically, even this shouldn''t be necessary. The uploader knows the size of the file name and everyone knows the size of the size. Either 1) declare a buffer of fixed size into which the name will be copied and sent, or 2) have the sender transmit the sizeof() the string before the string is sent. In the first case, the receiver already has an established amount to fetch, or can use what the sender said in the second.

An even better solution is to declare a struct with members for all this data and send it all at once so that you know the next thing in the stream is the file itself.

Share this post


Link to post
Share on other sites