Error in TCP transmission

[OZI]

Hi,
we are trying to set up a TCP transmission between two applications. The data stream have a size of 5802 chars. The server transmits all the datas without an error. But the client only receives 4392 chars. The rest of 1412 chars can be read in a second call of ClientTCPRead but the datas are corrupted.

does any one knows a solution for this problem ?

greetings
Oliver

[cosmo]

Hi OZI,

  The TCP data stream is busted into segments typically no larger than that protocol's MTU.  Depending on the O/S, this typically ends up somewhere less than or equal to 1500 bytes of data for TCP.  If you are receiving more than 1500 bytes during the first callback, I venture to guess that several packets have arrived--but not all of them.  The second callback allows you to access the data stuck in packets that are either in-flight (a matter or milliseconds, low probability) or that haven't yet been sent by the other end (just wait a few more millisecs longer, high probability).  If you wanted to test that theory, you could cause a 15 or 100 millisecond delay between the callback and the first read.

  Regardless, even a delay approach isn't a good one because TCP, by definition, is not deterministic--even though certain vendors try to convince you that their flavor is (a.k.a Ether/IP, etc.).  The only good approach is to store the first chunk until the remainder arrives.  You also need to consider that you might see another scenario.  Imagine two consecutive data streams, A and B.  You might get 3/4 of A in one callback, the last 1/4 of A and the first 1/6 of B in the second callback, and the last 5/6 of B in a third callback.  Your approach should ideally be able to separate the mixed A and B data in the second callback.  If you don't plan for this, the latency of the network and the loading of the CPU could make your software act strange.  And it would be almost impossible to debug since it is dependent upon the real world...

Orlan

[bilalD]

Cosmo is correct.

If you know in advance the number of data being transmitted, you could keep on reading the tcp data in a loop in the DATA_READY callback until all the required data is read. See this document for more information on how to set this up and for more information about TCP.

[OZI]

Hi Orlan
these are interesting points. I think it is not a problem of the delay before an callback because during my tests I was working with the debugger and I pass through the program step by step. So there was enough time between the callbacks.
but your first item bring me to an other idea. You wrote that if a data stream is bigger than the MTU value (normally 1500 bytes).... What is when I make sure that the program only send data stream with a size less than 1500 bytes ? is it then sure that the data stream is sent completely ?

Greetings
Oliver

[OZI]

Hi Bilal,
this is also an interesting point I will check this.

thanks
Oliver

[cosmo]

Hey OZI,

  Then, yes, I would agree with you that it probably wasn't the timing of the callbacks.  Hmmm.  Just sending 1500 bytes or less doesn't guarantee that it will go into a single packet either.  It may end up that way, but it isn't an actual TCP requirement.

  I have never personally seen CVI misbehave like this, so I wonder if the second callback is part of the problem.  Bilal pointed you to a document and there are several TCP sample apps in the sample folder of your CVI install.  Compare your TCP_DATAREADY event code with the sample client's event code.

  I wonder if your second read stream is getting corrupted with the first.  Are you using static arrays or pointers to the read buffer?  If static arrays are being used, look for null termination issues (tell TCP...Read( ) that the bytes to read should be 1 smaller than the static buffer).  Then make sure that you are using a string function that will merge null terminated strings with each other properly.  If pointers are being used, consider your malloc( ) use and make sure that you are joining the second callback's data with the first callback's data without overwriting some portion of it.  You are welcome to post just the TCP_DATAREADY piece of your code for us to look over.

Orlan

Message Edited by cosmo on 02-01-2006 10:54 AM