PC slows down if I timeout on clientTCPread()

[rorOttawa]

CVI 8.0.1 8105 PXI CPU winxp

It seems that the PC eventually slows down(after 100 loops) if I run a program that loops on a test where I am getting data over an ethernet socket and there is no data in the socket. I have to do it this way because sometimes there is data in the socket and if I do not check and get a timeout all the time I will miss the data.

The library function clientTCPread() seems to get all messed up if a timeout occurs.

The only solution is to read all the data into a large buffer and then process the data.

i.e.  bytesread=clientTCPread(handle,buffer,10000,1000);  // read 10000 or less bytes.

instead of

     bytesread=clientTCPread(handle,buffer,requirebytes,1000);  // where requirebytes is the header of my message

Is there a way to "peek' at the socket to see if any data, to avoid a timeout on library function.

[jr_2005]

The CVI TCP Callback mechanism already does this for you. As long as there is a ProcessSystemEvents () (or even ProcessTCPEvents()) call somewhere in your program loop, then if there is any TCP data waiting to be read this will activate your TCP callback with the TCP_DATAREADY event.

JR

[rorOttawa]

I have processsystemevents.

Yes I get the TCP_DATAREADY and then start to process the data like so:

- clientTCPread only 80 bytes(header of my message #1)

- determine remaining bytes in message and call clientTCPread to read only the rest of the bytes in this message #1

- message #1 is complete , return from interrupt

But sometimes I miss a message because in the last interrupt there were 2 messages that I should have read but did not.

If I do it like so:

Yes I get the TCP_DATAREADY and then start to process the data like so:

- clientTCPread only 80 bytes(header of my message #1)

- determine remaining bytes in message and call clientTCPread to read only the rest of the bytes in this message #1

- try clientTCPread only 80 bytes(header of my message #2 if there)

  Most of the time there is no other message there and I get a timeout error from the library call.

  This seems to eventually cause my program to slow down in serving ethernet messages so that my test fails because PC is too slow.

- return from interrupt if no message #2 else read rest of message #2

  The only way that I return from this sequence is by gettiing a timeout. 

during this program I am disconnecting/reconnecting the ethernet several times and I think the system is not dropping the handle and cleaning up memory for the old ethernet connections. Each time I reconnect I get another handle. It never uses the same handle value.

there is a function(GetHostTCPSocketHandle) to get the system handle that relates to the ethernet handle but what can I do with that.

If I do not try and look for the second message, I miss it.

The ethernet interrupt just says there is data available. It maybe a complete message or part of a message or several messages.

  Oh I see a function TCPFreeMemory(). I have not used that. Maybe that is my answer to call this function when I disconnect ethernet. ?

[jr_2005]

If there are two messages waiting for you when your TCP callback is serviced, but you only read one of them, then when the callback returns and another ProcessSystemEvents() or (similar) occurs, the remaining pending message will immediately re-trigger another TCP callback event, so you should not lose any data. As long as you keep synchronised with the protocol you have adopted, you should also not need to run into the timeout issues, either.

JR

[rorOttawa]

Yes you are correct if it all works properly.

We definitely saw that when a second message was present in the buffer, and we did not read it, the callback would not fire again, and the second message would be lost. Perhaps there was an update to the NI libraries to address this problem? 

[Mohan]

You may want to check out samples/tcp/message.cws - especially, MessageReader.c. Basically, this example program shows how to send and receive messages of varying sizes and uses a header of 4 bytes to indicate the message size.

[rorOttawa]

It looks like my problem is not ethernet but is caused by another thread that I created using

CmtScheduleThreadPoolFunction and the default tread pool.

the thread runs for 70 seconds and then exits using CmtExitThreadPoolThread

only to be repeated later many times over. program runs for 15 hours and then program slows DOWN to a crawl.

[dummy_decoy]

a program that gradually slows down over the time when doing the same thing over and over again is a sign of a memory leak (especially when running on windows). 

open the task manager on the performance tab, see if the memory used does not become too high.

there is also a function in the CVI library to help diagnose those problems: CVIDynamicMemoryInfo().