Winsocks: Send Methodology

Started by
11 comments, last by Prozak 17 years, 9 months ago
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...
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! ;)
"Absorb what is useful, reject what is useless, and add what is specifically your own." - Lee Jun Fan
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!
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]
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?
Discard the bytes that were sent and resend the bytes that have not been sent until they're gone for good :)

Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

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...
...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?
You know instead of trying to reimplement TCP/IP, you might want to just use TCP/IP.
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...

This topic is closed to new replies.

Advertisement