How often is TCP_DATAREADY generated?

[kirkm]

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

[SerJames]

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,

[kirkm]

James,

Thanks for the helpful information.

I have made several improvements to my code and have things working much better.

Rather than count on the callback to deliver TCP_DATAREADY events, I put a call to ClientTCPRead(...) in the polling loop that waits for and processes the TCP data as it comes in from the server.

Based on reading the documentation you referenced I also improved the code that handles the TCP stream to expect the consolidation and fragmentation that happens with the TCP data.

To re-iterate my question about the buffering of the TCP data:

I understand that I can specify how big a buffer that  ClientTCPRead(...) can use to read the data.  I think I have that handled.

What I'm still wondering about is:
The polling loop that is processing the TCP data as it comes in from the server occasionally gets busy doing something other than processing the TCP data.

During this time the micro continues to send data from the server. I assume that it must be getting buffered somewhere in the windows socket code or something.  The question is how big is this buffer and where can I adjust its size?  This will let me know (depending on my incoming data rate) how long my polling loop can be busy with other tasks.

Thanks again,

Kirk

[SerJames]

Hi Kirk,

This may be the best route you have.

http://digital.ni.com/public.nsf/allkb/A6ABC151D525C38586256B8400559CC5?OpenDocument

It looks like CVI does not expose (inherently) that sort of information and you will need to use the Windows SDK to play with that information. If what I am reading is correct, according to Wikipedia the default TCP window scale size is 65,535 bytes. (http://en.wikipedia.org/wiki/TCP_window_scale_option).

The above listed KB gives a couple of useful related links that should get you on the right track.

Regards,