LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TCP connection break / re-connect issue

Solved!
Go to solution

Yes, and the fact that between the time you check the refnum and the time your case structure executes, the refnum could have gone invalid. 

 

That's true, but I don't see it as relevant to this problem.  If that happened, I would then try to read from the invalid refnum, immediately return an error, set the refnum to NaN and then attempt to reconnect.

The only "race" problem is apparently on the OpSys on the other end.  Whether the ABORT gets thru the system and turns off the listener before the host recognizes the connection died and attempts to reconnect.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 11 of 19
(1,701 Views)
Solution
Accepted by topic author CoastalMaineBird

 


@CoastalMaineBird wrote:

Not a refnum just tells you if you have a valid refnum, it doesn't tell you you have a valid connection.

 

Sure, I understand that.  What I didn't know was that the test for Not-a-RefNum is NOT a simple test for zero, but a search thru some table somewhere.

 

It doesn't pertain to my orginal problem but it's interesting to know, nonetheless.


It's pertinent because you are using the Not A Refnum to tell you connect gave you a usable connection. You should do a read after the connect and wire the error from the read to the case structure that fires off the connected event. Ideally, in the server, you'd fire off a "Welcome" message upon connection so that the client would know the connection is usable.

0 Kudos
Message 12 of 19
(1,690 Views)

You should do a read after the connect and wire the error from the read to the case structure that fires off the connected event.

 

I tried exactly that

 

 

 

 

 

 

 

 

 

 Ideally, in the server, you'd fire off a "Welcome" message upon connection so that the client would know the connection is usable.

 

If I did that, and then only claim connection when the welcome message was received, then it would avoid the issue, because there's no way the other end sends a message after being aborted.  However, my architecture is such that the host sends a command, and the PXI sends ONLY in response.

 

However, the first thing I send is a VERSION? command.  I could postpone connection events until after the response is received, I guess.  But then I would have to SEND into a connection that I don't know about yet (because it hasn't CONNECTed, officially, yet).

 

No, it still seems like the best thing is to wait some fixed time.  I don't know EXACTLY how long, but it's not important to minimize it.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 13 of 19
(1,665 Views)

You should do a read after the connect and wire the error from the read to the case structure that fires off the connected event.

 

I tried exactly that, and nothing changed, nor would I expect it to.

 

I put a zero-byte read (which still checks the health of the connection) immediately after the connect, and check the ERROR output.  No behavioral difference.

 

Linkage 3.PNG

 

 

 

 Ideally, in the server, you'd fire off a "Welcome" message upon connection so that the client would know the connection is usable.

 

If I did that, and then only claim connection when the welcome message was received, then it would avoid the issue, because there's no way the other end sends a message after being aborted.  However, my architecture is such that the host sends a command, and the PXI sends ONLY in response.

 

However, the first thing I send is a VERSION? command.  I could postpone connection events until after the response is received, I guess.  But then I would have to SEND into a connection that I don't know about yet (because it hasn't CONNECTed, officially, yet).

 

No, it still seems like the best thing is to wait some fixed time.  I don't know EXACTLY how long, but it's not important to minimize it.

 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


LinkedIn

Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 14 of 19
(1,659 Views)

@CoastalMaineBird wrote:

You should do a read after the connect and wire the error from the read to the case structure that fires off the connected event.

 

I tried exactly that, and nothing changed, nor would I expect it to.

 

I put a zero-byte read (which still checks the health of the connection) immediately after the connect, and check the ERROR output.  No behavioral difference.


The zero byte read at best checks the refnum but doesn't involve any socket transaction that would physically check the actual connection. Even if it did that the TCP ACK and SYNC could still be handled by a lingering socket on the remote side before it gets properly garbage collected after the process abort.

Rolf Kalbermatter
My Blog
0 Kudos
Message 15 of 19
(1,651 Views)