TCP_DATAREADY event slows down TCP data

[kirkm]

I'm working on some Labwindows/CVI code that communicates with an embedded device using the TCP libarary.

The CVI code is a client that sends requests for data to the embedded server.

The request / response happens in a timer callback.

The code does not use the TCP library callback TCP_DATAREADY event to collect the data.  This event has no code in it.

Rather the code running in the timer callback calls ClientTCPWrite(...) to send the request to the server.
Then it waits in a loop and uses calls to ClientTCPRead(...) to collect the response data as quickly as possible.

Most of the time this works well.  The TCP_DATAREADY never gets called.

However sometimes, if I do something with the user interface,  like drag a window around or something it gets into a situation where it starts

calling the TCP_DATAREADY very rapidly.  This has the effect of slowing things waaaay down.  No data is read in the TCP_DATAREADY callback so it eventually gets all the data in the loop in the timer callback.

Is there any way to shut off calls to TCP_DATAREADY?

Or is there a better way to set this up?

Thanks,
Kirk

[Kurt-P]

Hey Kirkm,

What does the CPU look like when you drag the Window around?

Is there anything else that cause TCP_DATAREADY to fire?

You may want to call ProcessSystemEvents (); to see if there are any errors that are not being handled when you make the move. Help for the file:

http://zone.ni.com/reference/en-XX/help/370051V-01/cvi/uiref/cviprocesssystemevents/

Best Regards,

-KP

[Gaus]

If you do not need any TCP callback then setting  the ConnectToTCPServer() callback function to 0 may work for you

[kirkm]

The CPU usage goes up significantly when it gets in this "state".

It's not really while you're dragging the window around, rather it seems like causes it to start a vicious cycle where it makes very many calls to the TCP_DATAREADY event.

I put a counter in the TCP_DATAREADY callback. When I start the code that requests data from the server and check the counter it hardly ever counts up.  Then if I move the window or click a button that starts some data logging boom! the counter starts counting up like crazy.  It's as if my code that is polling ClientTCPRead(...) gets interrupted long enough to allow a TCP_DATAREADY event and from then on it always calls TCP_DATAREADY as fast as it can??

I put a SetCtrlVal(..) in the TCP_DATAREADY event to display the counter and when it gets into the "bad" state it REALLY! slows down.

Not surprising I guess because the user interface update takes a long time.

The reason I'm polling ClientTCPRead(...) is that I want to respond as quickly as possibly to the incomming TCP data.  If I knew how often TCP_DATAREADY events are generated I may be able to "centralize" my data reading in the TCP_DATAREADY event.

I tried putting ProcessSystemEvents() calls in various places.  Didn't seem to change the symptoms.

Any more thoughts?

Kirk

[kirkm]

Gaus,

Setting the callback in ConnectToTCPServer() to NULL gets rid of the symptoms of the problem.  No more slow downs.

Without the callback the code doesn't have access to the TCP_DISCONNECT event. 

Do you know of any other way to detect that the server has disconnected from the client?

Thanks,

Kirk

[proton029]

Could you share ur version of tcp code?

[holly7787]

also think to use a thread instead of a timer to process the TCP READ request, you won't have problem while using the UIR