LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TCP Open Connection and Error Code 1

So, I have a client that is supposed to continuously try to connect to a server using TCP Open Connection.vi. When the connection is established, the loop is supposed to exit.
 
psuedocode for the loop I have is as follows (similar code, LV 7.1, exhibiting the same problem is attached)
 
while (error)
  attempt to open connection
 
Pretty simple, right?
 
I've had no issues with servers written in LabVIEW, but when attempting to integrate with a server that was written in C, it appeared that the client created multiple connections. I have been able to reproduce this problem by writing a server with Java. The C server was on a remote machine, the Java server on a local. Both see different numbers of additional connections (3 for C, 2 for Java).
 
Looking at the error codes, I am getting a bunch of code 56 (timeout, expected) and the ocassional code 1 (unexpected). I have noticed that whenever I have this multiple connection problem, I show an error code 1 right before the valid connection attempt and loop exit. Is there someway that a connection is being established (or partially established), but labVIEW is still returning an error? Is there a better way to verify that a TCP connection was actually successful?
 
Here is example output from the attached code, it shows the error codes generated
56
56
56
1
56
56
56
56
56
56
56
1
56
56
56
56
56
56
56
1

 
Here is output from my Java code
[2006-05-24 15:43:23.556] - Begin Listening for Connection Attempts
[2006-05-24 15:43:23.587] - Accepting Connection
[2006-05-24 15:43:23.603] - Begin Listening for Connection Attempts
[2006-05-24 15:43:23.603] - Accepting Connection
Running ServerNIOConnection Thread
[2006-05-24 15:43:23.603] - Begin Listening for Connection Attempts
Running ServerNIOConnection Thread
 
Thanks,
 
Martin
 

Message Edited by mmathis2000 on 05-24-2006 05:50 PM

Message 1 of 3
(2,828 Views)

Hello,

 

I’m a little curious why you are setting up your client like this.  If it is your objective to just have the client wait until a connection is made, why not just have the TCP connect VI have timeout value of ‘-1’ meaning “do not timeout”.  This will allow the built-in TCP event structure to listen for connections and ‘wake up’ your program when a connection is established.  I say this, because the error messages seem to be dependant on the timeout values.  For example, wire in 1ms to the timeout and see how the messages differ in timeouts as opposed to wiring in “2000” for the timeout value.  This is because the Connect VI attempts a connection and waits only the specified timeout before abandoning that attempt and continuing with another attempt.  I’m betting in your case connecting to the server takes longer than your timeout value, so the connection is initiated by your LV client, the handshaking takes place, your server indicates that a connection is being made, and sometime during this process your timeout expires and LV tries the process again thus you see the multiple connections.  Go ahead and try this as an experiment – take your VI, and instead of using ‘localhost’ use the IP address of your favorite website and change the remote port to port 80.  Change the timeout to -1 and wait for the connection, then change the timeout to 1 and see all the timeout errors given.

 

Hopefully this answers your question, please let me know if you have any additional questions or if this is inaccurate/unclear.


Travis M
LabVIEW R&D
National Instruments
0 Kudos
Message 2 of 3
(2,808 Views)
Thanks for the tip, I just tried my software with the default timeout and it consistently produces error 63, and I have yet to see the same error I was having before. I guess defaults exist for a reason, eh? 🙂
 
The reason why I wanted to minimize the delay was because there is a stop button and I wanted it to be semi-responsive. Anyway, good to know and I think that might've solved the problem.
 
Thanks,
 
Martin
0 Kudos
Message 3 of 3
(2,802 Views)