tcp callback question

[Vishi Anand]

I am using CVI 7.0.

When exactly is the tcp call back called and how often? Is it called for
every char received or every pkt received?

Reason I ask is that I am seeing a problem where my program gets stuck
in tcp callbacks, even when I am not doing anything in that callabck.
Here is what I am doing

I do ClientTCPWrite to send a command to my device
Then I call ClientTCPRead with timeout of 5 seconds.

My tcpcallback is as follows:

static int CVICALLBACK ClientTCPCB(unsigned handle, int event, int
error, void *callbackData)
{
return 0;
}

What I have seen is that when I get a response from my device, my
computer CPU util is 100%. If I break execution, CVI is in tcp callback
fn. My device only sends data worth 1-2 ethernet pkts.

In my case,
I don't care at all about tcpcallbacks. All I want is send
some command and wait for a while to see if I got the response. I have
not had these problems in CVI 6.0 so wondering if anything changed in 7.0.

Did an experiment, where I sit in a loop after sending the command (this
loop had ProcesSystemEvents) and added printf in the tcpcallabck. There
were bunch of printfs indicating that tcpcallabck was being called all
the time. During this CPU was at 100% (even if I had no printf statements).


vishi

[JuanCarlos]

Hello Vishi,

How can I replicate this? I've been playing with the CVI examples to see the behavior, but I get only 1 callback with every packet and the processor does not goes to 100%. One thing that you can give it a try is adding to the printf the event value that you get in the callback, just to know what event is the one firing the callback.

Anyway let me know what am I missing here to replicate it and take a closer look at that.

Regards,

Juan Carlos
N.I.

[Vishi Anand]

Juan,

What I did to replicate is modify the tcpclient application. In
tcpcallback, I removed call to tcpread when event == TCP_DATAREADY. Now
from the server, if I send some data like "hello", the tcpclient takes
up 100% CPU and gets hung up in tcpcallback.

I am including my modified tcpclient app. All you have to do is run
server and then run client. Then from server, try to send some chars.

BTW - I am using CVI7.0 on win2000. I never seen this behavior in CVI.
For now I have a solution using winsock calls.

This doesn't happen if I do a tcpread in tcpcallback. I also put a
counter which I increment on TCP_DATAREADY event. Then I printed this
counter. I got a value > 10k.


vishi



JuanCarlos wrote:
> Hello Vishi,
>
> How can I replicate
this? I've been playing with the CVI examples to
> see the behavior, but I get only 1 callback with every packet and the
> processor does not goes to 100%. One thing that you can give it a try
> is adding to the printf the event value that you get in the callback,
> just to know what event is the one firing the callback.
>
> Anyway let me know what am I missing here to replicate it and take a
> closer look at that.
>
> Regards,
>
> Juan Carlos
> N.I.

[Mohan]

Vishi,

The TCP library calls the callback if there is ANY data to be read. So if you do not read the data, the library will keep calling your callback every time events are processed. This is the reason you see the printfs and the 100% CPU usage (basically the thread is very busy calling you callback again and again).

To stop the callback being called again, read the data. Note that the callback will be called again if you have not read all the data, or if new data has arrived.

Best regards,
Mohan

[Vishi Anand]

Thanks Mohan,

That's what I am seeing. I was thinking that callback will get called
for a bunch of data which comes at one instance (like 1 pkt). If I don't
read, the underneath CVI would not bother me again, but I know, I am wrong.

BTW - Why does CVI TCP fns. need this callback. Why not provide a way
where I can pass NULL for case I don't need the callback. That way I can
decide if I need to use callbacks or not (like RS232 library), rather
than forcing me.


vishi

Mohan wrote:
> Vishi,
>
> The TCP library calls the callback if there is ANY data to be read. So
> if you do not read the data, the library will keep calling your
> callback every time events are processed. This is the reason you see
> the printfs and the 100% CPU usage (basically the t
hread is very busy
> calling you callback again and again).
>
> To stop the callback being called again, read the data. Note that the
> callback will be called again if you have not read all the data, or if
> new data has arrived.
>
> Best regards,
> Mohan

[Mohan]

Hi Vishi,

The TCP library requires the callback because the implementation is built on top of asynchronous sockets, and these have the same constraint (will keep posting events until there is no more data to be read from the socket). CVI encourages event-driven programming as opposed to polling, and so, if you want to get the data, using callbacks is typically more efficient than polling, at least in CVI. Also, most use cases would need to read the data (and not ignore it), and so I guess, the original designers used asynchronous sockets and required the callback to not be NULL.

The latest version of DataSocket supports both event-driven (the old model) as well as polling (new model).

- Mohan