ClientTCPCB TCP_DATAREADY events stop even when new data is present.

[jtush]

I am using the following code to read the incoming TCP traffic.  I am sure that the ProcessSystemEvents () is being called (verified w/breakpoints).

After a while of successful TX/RX exchanges the callback event does not occur for TCP_DATAREADY.  It is not predictable when the TCP_DATAREADY event stops.

I have used a sniffer program to ensure that there are bytes on the TCP input port.  I have turned off all firewalls.

If I disconnect the server, the TCP_DISCONNECT event happens, but it can take 10-20 seconds before it is called.

I am using CVI 7.1.

INT32 CVICALLBACK i32ClientTCPCB (UINT32 u32Handle, INT32 i32Event,
                                  INT32 i32Error, void *pCallbackData)
{
    char szTempBuf[MAX_QUEUE_SIZE];
    INT32 i32BytesRead;
   
    mi32Err = 0;
    switch (i32Event)
    {
        case TCP_DATAREADY:
            DisableBreakOnLibraryErrors ();
            do
            {
                if ((i32BytesRead = ClientTCPRead (u32Handle, szTempBuf,
                                                   MAX_QUEUE_SIZE,
                                                   mu32RxTxTimeOut))
                    > 0)
                {   //remove garbage at end of buffer
                    szTempBuf[i32BytesRead] = NULL;
                    strcat (mszReceiveBuf[u32Handle], szTempBuf); // build receive string
                    strcpy (szTempBuf, "");
                }
                else if (i32BytesRead != -11)
                {   // save error code if not timeout
                    mi32Err = i32BytesRead;
                }
            } while (i32BytesRead > 0);
            EnableBreakOnLibraryErrors ();
            break;
        case TCP_DISCONNECT:
            MessagePopup ("TCP Client", "Server has closed connection!");
            break;
    }
    //The return value of the callback function is ignored.
    return 0;
}

[AEDavid]

Hi JTush,

I would recommend

• calling GetTCPSystemErrorString to see if there are any errors
• removing your do/while loop and making your client callback function just like the example project client.prj.
• calling ClientTCPRead and seeing if it will retrieve data, even though it is not firing an event. 
• making sure BreakOnLibraryErrors is enabled while you are waiting for events
• set your debugging level to extended or standard to detect an errors

[Nicolas S.]

Hello jtush,

I have exactly the same trouble !

Did you find an issue ?

I found that if I call the ProcessTPCEvents() function with a control callback, it generates the TCP_DATAREADY event and the TCP callback is called ! But I cannot know when I need to do so and I cannot do it all the time !

I found this answer in the knowledgebase Changing the TCP Window Size but it doesn't explain anything.

If you have found an issue, please tell me!

Nicolas

[Mohan]

The CVI TCP events are just like UI events. They can only occur if your program (thread) is processing events - by calling RunUserInterface or continuously calling ProcessSystemEvents or ProcessTCPEvents.

But the CVI TCP library can also be used without events - you can always call the TCP Read functions (client and server functions) anywhere in your program and they will just return an error if there is no data to read. Nicolas, this is probably a better solution for you since you mention that you are not sure when exactly your program knows to call ProcessTCPEvents.

jtush, I am not sure why the events stop occuring for you - if you are using ProcessSystemEvents instead of RunUserInterface, may be there are too many events happening in your system per call of ProcessSystemEvents. You can try using RunUserInterface instead. Also, try running the shipping server and client example programs and see if they work fine.

[jtush]

My solution was to remove the do-while loop.

I am not sure why this fixed the problem.

I only had to protect higher-level functions against recieving a partial message.

[Nicolas S.]

Mohan, I am currently calling the RunUserInterface() function and then I am waiting for TCP or UI Events.

After having called the ClientTCPRead function on a TCP_DATAREADY event I am doing some instructions to process the received data (not only a printf or something else). But after a not predictable time the TCP_DATAREADY event stops. To analyze the problem, I set a control in the User Interface to force a ProcessTCPEvents() call and it works, the TCP_DATAREADY event happens. Then it works fine until the next time the TCP_DATAREADY event stops.

Jtush, thanks for your answer, I will try to make a function with my processing instructions of the received data.

Nicolas

[Mohan]

Nicolas, could you post some simplified version of your code that others could run to reproduce the problem? When you stop receiving the TCP events, break into the program in the CVI debugger, and check where it is suspended and check the call stack (Run menu >> Stack Trace). The program could be waiting in some location other than RunUserInterface or it could have gotten nested deeply if you are calling RunUserInterface, ProcessSystemEvents, or ProcessTCPEvents from your callback functions.

[Nicolas S.]

Mohan,

I will try to do a simplied version of the code as soon as possible. It is based on the server/client sample. After having read some data, I process them directly in the callback. When I stop receiving the TCP events, I saw by breaking the execution that I am waiting in the RunUserInterface of the main function and doing nothing. There is only one thread (and another one I don't know but I expect this is a thread of CVI) and nothing in the call stack other than the main.

To do a test, I created a function to make the processing of the data and I call it just after having read the data. It seems to make a difference because I did not succeed to reproduce the problem.

However I didn't understand why it could be different and solve the problem.

Nicolas

[Nicolas S.]

I have maybe something else...

I am using Labwindows/CVI 7.1 but I just installed the last evaluation version...maybe an update of some DLLs...