LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

LabWindows clientTCPRead() and windows threads.

Solved!
Go to solution

Howdy!

 

Curious to know whether this is "works as designed" or if I have uncovered an unknown error.  I have an application that has various commands that can be fed down to a cRIO.  Thinking to serialize the commands, I have installed a TCP writer thread that maintains its own queue to post all messages serialized.  We are also getting lots of data back from the cRIO, so I have a reader thread as well.

 

Early on, I found that I could not start up the link from an arbitrary thread and write to the link.  I thought that was rather odd, but I went with it.  I made the writer thread open and maintain the network link.  When I got to the point where I was starting to pass data up and was attempting to figure out where I had brokenness, I found that I the connection from the reader thread always returns either -11 or -12 (kTCP_TimeOutErr & kTCP_NoConnectionEstablished).  In my networking code file, I have the session as a static.  I have access to i from either thread without issue, but it seems like NI is doing something under the hood to make sure that only the thread that opened the socket can access it.  Also, I'm not ever getting a call-back for data present.

 

Just to be sure that it was as we suspected, I did read data from the my tcp_open() function and was able to read it.  I can also read data ANY TIME from the writer thread (the one that opened it), but the session does not work from another thread.

 

To be clear:  I am not using the NI threads, but rather Windows threads (as I was doing some additional things with them).

 

I'm switching to the normal Windows sockets at the moment.  If you have any light you can shed on this one, please let me know.

 

Another note:  the previous version of this software had everything running out of a thread pool -- the open was actually done in a spurious thread that was started and stopped when the connection was established.  So, that thread, though it went away, was still under management of the NI API.

 

Thanks in advance for any information you can provide.

 

Andy

0 Kudos
Message 1 of 2
(126 Views)
Solution
Accepted by topic author MAKennedy

I do not have a definitive answer.  I can only describe what I've seen.  BUT, what I believe to be the "right answer" is that NI's implementation of TCP Sockets includes recording the thread ID of the original requestor.  If the thread ID of the caller of clientTCPRead() or clientTCPWrite() is not the original requestor, the function returns -kTCP_No_Connection even if there is one.

 

The only fix is to use the OS level sockets WinSock.  There are two examples on-line for the server and client.  Search for "Complete Winsock Server Code" and "Complete Winsock Client Code" to get you started with working socket code.

 

Andy

0 Kudos
Message 2 of 2
(85 Views)