• Advertisement
Sign in to follow this  

Winsocks: Send Methodology

This topic is 4216 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm experiencing packet-loss on an app I'm developing, on the receiving side. On the sending side, all I'm doing is reading from a file, and sending, no stops. Is this wrong? Should I wait for a "packet-received" message before sending another one out? Or does Windows handle this with a buffer on the receiving end? On the receiving end, I get some packets, and lose some packets, but I can't precise exactly what is going wrong...

Share this post


Link to post
Share on other sites
Advertisement
Are you losing packets, or just some of the information?

One of the things to check is that the send function is definitely sending everything in your buffer. For example, you might read 2048 bytes and call send. send might only send 1024 of those in one call. If you assume that it has sent all 2048 and send the next 2048, you will have lost 1024 bytes.

Other than that, nothing obvious comes to mind.


btw - good luck tonight! ;)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Is the function "send" or "sendto"?
If send then you are using TCP in which you really shouldn't loose any packets, we maybe able to see the problem if we could see your code.
If your code is not error checking socket functions and returns don't expect much help!

Share this post


Link to post
Share on other sites
ah! I wasn't thinking of the send size, and was sending packets of 8Kb in size, maybe a bit too big for the send command.

Ps: Thanks, I really apreciate that coming from an English soccer fan. Let's see what the Gods have instore for us tonight [wink]

Share this post


Link to post
Share on other sites
hmmm... ok...

...but how does one proceed when the Send function returns a value that is not the amount of bytes you intended to send?

Share this post


Link to post
Share on other sites
I've reduced the packet size, and now I have on the Sending side a delay, so that I don't "swamp" the receiving side with data.

How do I manage to send data as fast as the receiving side can manage it?

If I just read from the file and send it off, then I think the buffer on the receiving side gets an overflow...

Share this post


Link to post
Share on other sites
...should I, on the receiving end, send out a "I've got your latest packed" message, or something along those lines?

...so that the sender can pace itself and not overflow the receiver?

Share this post


Link to post
Share on other sites
You know instead of trying to reimplement TCP/IP, you might want to just use TCP/IP.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
You know instead of trying to reimplement TCP/IP, you might want to just use TCP/IP.


I am!

Ok, a bit of background on this then. This is an utility designed to transmit data, including large files, from a PDA to a PC, using winsocks and TCP/IP Protocol.

It's designed in such a way that allows two threads to have a communications-line between them. A thread on the PDA can talk to another thread on the PC. Each of these CommThreads has an in-Buffer with an Event attached, so that they can wait for something to arrive on that buffer, without using CPU time.

A master CommThread using a base protocol on top of TCP/IP knows which packets are to go to which buffers, and signals those buffers, so that any Thread waiting on data to arrive can awaken and process it.

So, it makes heavy use of threads, mutexes, events, etc... pretty complex design making bug-catching a royal pain in the behind...

Share this post


Link to post
Share on other sites
Simpler design: don't do packet switching in your protocol. Instead start a new socket connection for a file transfer and just have the sender send() and the receiver recv(). Then you get to use the buffers and packet switching and congestion handling routines of the TCP/IP stack.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
Simpler design: don't do packet switching in your protocol. Instead start a new socket connection for a file transfer and just have the sender send() and the receiver recv(). Then you get to use the buffers and packet switching and congestion handling routines of the TCP/IP stack.


Where can I learn more about congestion?

It seems that if the receiving end lags behind a bit, then the sender will overflow the receiver.

I did a test where I sent packets 64.000 bytes in size, and ocasionally the receiver would receive more or less than 64.000.

Now, because my protocol has a header in the first few bytes of the packet, weird stuff might occur.

hdddd (header + data)

If there is overflow and the packet gets broken in two:
hdd <--- things might go wrong, but at least I have the header
dd <--- things will definitly go wrong here, as I expect a header

So, how to get around this congestion/ overflow issue? I've reduced errors to a minimum by reducing the packet size to 1.000 bytes, and doing this:
1. send
2. wait for receiver to say it has received the packet
3. send another

...but this feels like hacking, and with this method there is a lot of wait time going on, and I feel I'm losing a lot of transmission speed...

Share this post


Link to post
Share on other sites
I think I found a solution, when I realised that even though the packets might not arrive fully, they will at least arrive in order.

So, I changed the algorithms so that data will only be processed once we have a full packet. It goes more or less like this:

1. Packet "h3dd" arrives. The header states that the data is 3 units long. As you can see we only received two units (dd).

2. Packet "dh1dh" arrives. Now, the previous packet wasn't complete, so we add the previous one to this one, we get "h3dddh1dh". If we break it up we get "h3ddd h1d h". This means I can process the first two headers already as the 3rd hasn't yet completely arrived, we still don't have all the data for it to be correctly processed.

Comments are welcome...

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement