Flush TCP connection

[hiNI]

Hello,

I am trying to capture data from the TCP connection, however, there are instances where I may only have say 5kbytes of data and when I have a lot more.  If I take the 'bytes to read' beyond 6000, the program hangs.  

Is there some way to flush the TCP connection so that when I send the next set of commands over the TCP connection, I can just capture the current set of data instead of the whole bunch of data that is sent from my machine?  

To give you a better understanding of my overall program, I am testing out a device over TCP.  Only if I reset the device and send a read command, I get some of the data from my attached program.  Because I am just limited to setting the 'bytes to read' to 6000, I cannot capture all the data.  Is there another way to caputure all the data after the device reset?

Thanks,

hiNi.

[smithd]

When you say hang do you mean "hang" or "waits until the timeout I specified", because thats a pretty important distinction. You should certainly be able to read 6 kB from a tcp connection. I'm going to assume the second option because the first option is a far more serious problem.

I'm not 100% sure I understand how your device works, but two thoughts come to mind which might point you in the right direction.

One is that it sounds like you need some sort of framing on top of TCP. Most TCP protocols will have some sort of user-defined header which might be as simple as a length value, and then the data follows. If you look at the TCP examples in LabVIEW, thats what they do. Does your device have anything like this?

The other point is that TCP read has a "mode" input. For your purposes it sounds like you might want "immediate" mode, but if your device is a converted serial device it might also be appropriate to use CLRF mode.

[rolfk]

TCP has several mode inputs that you should look at and understand. The online description is pretty conclusive about them.

Basically your read function does not hang but waits for the specified timeout which by default is set to 25000 ms. There is nobody that forbids you to specify a different timeout. For instance TCP Read with a timeout of 0 or 1 will return instantaneously no matter how much data is available. Together with the mode Immediate, this will flush whatever data is present if you use a big enough number of bytes to read. You can verify that the number of bytes returned is smaller than what you have specified to read and if that is not the case issue another read with the same conditions until you receive a buffer that is smaller than you specified to read.

[htoton]

I have the same issue with TCP read latency when reading form sbRIO .I tried what you suggested still can not reduce TCP read latency. I think when using two targets : RT - sbRIO ( write to TCP port) and Windows(read from TCP port) latency issue become inevitable since Windows and RT OS using two different buffering on TCP stack . Windows TCP buffer size is not changeable by user ( it can be seen through regedit) as well sbRIO ( or I do not know how).

I tried to improve the latency by loop timing  and have the TCP read loop on Windows iterate at 5  ms rate, just a little improve , I do not know how much that timing will  obeyed by Windows none-deterministic OS.

is there any work around the latency issue or perhaps that what it is and I should look to change the whole data structure and write less bytes on TCP port?

Thanks for the help