Click to See Complete Forum and Search --> : Losing TCP/IP Data


ybotha69
June 9th, 2004, 09:17 PM
Hi All,
I have a problem where I am expecting TCP/IP STREAM data to arrive in "chunks" of a set size. Occasionally the remote system sends 2 x of these "chunks" as one TCP/IP packet.

When that occurs, my WSAGetOverlappedResult(..) only appears to extract the last of half of the co-joined packet (i.e. the 2nd "chunk").

Is there a way to interrogate WSAGetOverlappedResult() to check for more data or should I check with WSARecv() ?

NB: I use only 1 x WSABUF and the buffer in it is set to the size of only 1 x expected data "chunk".

cheers
Will Beattie

j0nas
June 10th, 2004, 10:15 AM
You may get the data in any size... Don't expect to receive the same number of bytes (in the same call) as the other end sent.

kuphryn
June 10th, 2004, 12:05 PM
The key is to either know the exact size of the incoming data or to know some know of unique character or code that indicates the end of the data.

Kuphryn

ybotha69
June 10th, 2004, 07:11 PM
Hi and thanks for the input ..

But, that doesn't appear to be the problem.

I am using a Packet Sniffer and have verified that the packets (various sizes) are getting to my PC. But the are not all reaching my application. I am using WSARecv and WSAGetOverlappedResult with just 1 x buffer.

The remote system is pSOS based.

Is there any situation where winsock will discard incoming data ?

cheers
Will Beattie

kuphryn
June 10th, 2004, 11:51 PM
Some packets may not be valid data either.

Kuphryn

Mathew Joy
June 12th, 2004, 02:14 AM
For an established tcp/ip connection not every packet send to and forth is meant for your application. But the thing you have to verify is whether your app get all the data that is send by the peer app. If you don't, then the possible reason could be as mentioned already, that your program doesn't take into consideration that you may get any no of bytes. The following faq (http://www.codeguru.com/forum/showthread.php?s=&threadid=296198) may help :cool:

ybotha69
June 13th, 2004, 12:54 AM
Thanks again for the input.

Q1.
What I would like know is: if I call WSARecv(.,.,.OVERLAPPED != NULL.) and it succeeds - should I process the RX data immediately ? or should I still call WSAGetOverlapped(..) to process the data ?

Q2.
If a packet arrives that is larger than my assigned buffer what happens to the extra data - is it still there for access by subsequent WSARecv() calls ?

Thanks again

cheers
Will Beattie

Mathew Joy
June 14th, 2004, 12:42 AM
Originally posted by ybotha69
Thanks again for the input.

Q1.
What I would like know is: if I call WSARecv(.,.,.OVERLAPPED != NULL.) and it succeeds - should I process the RX data immediately ? or should I still call WSAGetOverlapped(..) to process the data ?MSDN is not very clear in that (only certian hints). But the fact is that even if the recv completes immediately, you'll get the completion notification because your socket is already associated to a completion port and all the overlapped initiated operation will be queued to the completion port when it is completed successfully.

Q2.
If a packet arrives that is larger than my assigned buffer what happens to the extra data - is it still there for access by subsequent WSARecv() calls ?
If your buffer becomes full (assuming more data has arrived, than the submitted buffer) your recv call completes. The excess data is then buffered in the intermediate buffers. And you should try to read the data off as quick as possible, thereby freeing them.

ybotha69
June 14th, 2004, 02:46 AM
Hi Mathew,

Thanks for your invaluable help.

I agree .. MSDN does not explain WSARecv and WSAGetOverlappedResults very well !.

After reading the replies to this thread, I re-examined my RX state machine and the rest is history ...

Answer::blush:
Occasionally the state machine would do 2 x WSARecv without an intermediate WSAGetOverlappedResult (sic). AND, on very rare occasions when there was data in the buffers it would be over-written and that explained the loss of packets.

I hope my experiences may help others.

cheers
Will Beattie