Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

winsock 1.1: developing/refining a File transfering function.Need help

Status
Not open for further replies.

HJB417

Technical User
Jul 23, 2001
23
0
0
US
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(). )

=============================================
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
 
OK, you need to make a mental shift when using Winsock. It's obvious that you're expecting the data to come across in the same size packets as left the other machine, but in fact, TCP/IP and/or the network will sometimes break the packets up into smaller chunks in order to fit through some routers that have smaller buffer sizes.

In order to accommodate this behavior, you need to send the total length of the file to be transferred as the first thing you send. And when you start to receive, look for those bytes first to know when to stop receiving. When you receive each packet, simply append it onto what you've received before, until you hit the total byte count (which might come mid-packet, BTW).

Here's a tip: In case you need to send the file across different CPU architectures, use the htonl() and ntohl() functions to make sure the filesize bytes get swapped correctly (or not).

Hope this helps.
Chip H.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top