How often is TCP_DATAREADY generated?

Question

What I'm doing:
I'm working on adding a Wi-Fi module to a product that uses a small embedded micro-controller.
The micro operates as a TCP server communicating via Wi-Fi.
I've developed a LabWindows/CVI application to display the data that the micro collects.
In one mode of operation the micro delivers a continuous stream of 20 byte frames.
The frames are sent at 3200 Hz.
The LabWindows/CVI code connects to the micro as a client and then sends a command to start the 3200 Hz stream of frames.
In the TCP callback function (the one that is registered with the call to ConnectToTCPServer(...) )the TCP data is read and handed off to the rest of the application.
The problem:
The TCP callback where it handles the TCP_DATAREADY case is not called often enough to keep up with
the stream of data.  ( I am calling ProcessSystemEvents() in the loop that waits for data)
My questions:
How often can I expect to get a TCP_DATAREADY in the TCP callback?
How much buffering of the incoming TCP data is there?
In other words how long can my code be "away" from the callback before things get too backed up?
One other thought:
Everything has been working well using a directly connected serial interface running at 2 mega-baud
to connect to the micro.  With the serial connection there is large buffer on the COM port so I have
a fairly long time before the code has to get back to process more incoming frames.  I'm trying to
emulate this same behavior with the TCP client-server setup.
Any ideas will be appreciated, thanks,
Kirk

Answer 1

Hi kirkm,
I was able to do a little digging and did find an available knowledgebase article on this particular flag. You can find it here
http://digital.ni.com/public.nsf/allkb/C5CC85D98C771FC78625768500565FAF
It appears the TCP_DATAREADY event of a callback still requires a call to ClientTCPRead. In that function you can specify your data buffer size. That could be one approach to making sure you get the data needed, by specifying your given buffer size.
Reading up on TCP Communication found at http://www.ni.com/white-paper/3067/en There is a section on how to react to the streaming nature of TCP. I will quote that section for reference:
"In TCP, because data is sent in a byte stream, it is not possible to know how many bytes are present in the data stream. Therefore, you cannot query the LabWindows/CVI TCP Support Library to get the amount of data available. When you call ServerTCPRead or ClientTCPRead, the library returns the number of bytes read into the data buffer. If the number of bytes read is the same as the data buffer size, then more data still might be present in the data stream. You can read the remaining data immediately by calling the read functions again or wait until the TCP callback is called again with the TCP_DATAREADY event. The LabWindows/CVI TCP Support Library calls the TCP callback with the TCP_DATAREADY event whenever events are processed and there is data in the TCP stream. Refer to the LabWindows/CVI samples\tcp\message.cws sample program for code that shows how to read all the data in the TCP stream whenever the TCP callback receives a TCP_DATAREADY event. The ServerTCPWrite and ClientTCPWrite functions return the number of bytes written to the TCP stream, which might be less than the number of bytes in your data buffer. You must check for this condition and make sure all the bytes in your data buffer are written out successfully. The following code, based on code in the samples\tcp\messagewriter.c sample file, demonstrates how to check for this condition."
Hopefully that will get things started.
Regards,
James W.
Applications Engineer
National Instruments