Problems with CVI and TCP/IP

[OZI]

Hi,
we developed an application which runs on two computers and communicates between the computers. The communication runs perfect if we run it under CVI. When we compile it and run it as stand alone executable the communication have problems. That means, it does not run proper and datas get lost.

Summary:
- the application runs under CVI
- it does not run proper as stand alone executable
- we are using CVI 5.5 P1
- we are running win win2k

greetings
Oliver

[OZI]

Sorry,
I forgot the question.
Does anybody know why the application does not run as stand alone executable? Is there a known bug in the compiler ?

Can anybody help?

thanks
Oliver

[Philipp R.]

Dear Oliver,

afaik there's no known systematic error with the TCP implementation in CVI 5.5 ...

Please try to run your program with a newer version of the CVI runtime engine or compile/run it in a newer CVI version to see whether the behavior is the same.

Best regards

Philipp R.

[kohlmaier]

Hello.

I have a similar problem - and still NO solution.
So here is my story.

 - we have developed our application with cvi 5.5.1 and it was running well as standalone EXE.
 - when we disabled some debug logs (which have nothing to do with the TCP communication) to get better performace, we started to loose TCP frames about twice an hour. (so the loosing of TCP frames may be affected by the application timing)
 - we discovered that the TCP callbacks (where the databytes were read and processed) can cause some problems regarding the reentrance we cancelled the callback and implemented a reading-thread. With this approach we lost TCP frames only once an hour.
  - the more debug logs we added to find the error, the less TCP frames we lost (good working - but bad performance !)
  - we captured the TCP communication with a sniffer program (wireshark) and discovered, that the databytes were REALLY sent and REALLY arrived at the tcp server - but the server function ServerTCPRead does NOT deliver the bytes. So the error must be inside the cvi runtime.
 - Then we upgraded to the cvi runtime 8.5 and the error seems gone (seems !)
 - our application worked well as standalone executable (compiled with cvi 5.5.1) under cvi runtime 8.5 with all debug logs disabled at best peformance for over one week without any error - till today: the error occured again.

So what now ?

[OZI]

Hi,
last week I made also a test with the CV 8.5 and there was the same problem like on CVI 5.5.

I also expected that the problem is inside the runtime and is related to the reentrance of the callback. In my opinion there is a relationship between the number of datastreams we send in a minute and the number of lost frames. Perhaps there is a problem with the reentrance in the callback. That means that there is a problem if new data arrive before the callback is finished.
To avoid problems we integrated a checksum in our datas and when we "loose a frame" we can find it because the checksum is wrong.

Our tests last week showed us that the problem is the same for the 8.5 and 5.5 version of CVI.

The interesting thing is that we have some customers where the application runs proper. At our customer there is absolutely no chance to run the application. For this reason we expected, that the general problem bases on the network itself, but meanwhile we can exclude this. We checked the networks and the transmissions are ok.

So, the probalility that there is a problem inside the CVI runtime is very high.

How to go on now ?

Greetings
Oliver

[Mohan]

The CVI ClientTCPRead and ServerTCPRead functions basically just call the Windows Socket (winsock) recv function to read the data. recv should return WSAEMSGSIZE if the message was truncated and if so, the CVI read function will return a library read-failed error and set the appropriate system error that can be retrieved by calling GetTCPSystemErrorString. You may want to check for this in your program. Also, you may want to replace the CVI TCPRead functions with your own calls to recv to see if that avoids this problem. To call recv, you will need the full SDK support, and will need to #include the winsock2.h SDK file and add the ws2_32.lib SDK file to the project. Also, recv uses the socket for the connection - you can retrieve this using GetHostTCPSocketHandle and casting the output int to SOCKET. I think the problem is either in winsock itself or due to some timing issue in the CVI TCP Read functions - in either case, using recv directly should shed some light on this.