12-01-2014 07:13 PM
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.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
12-01-2014 07:19 PM - edited 12-01-2014 07:32 PM
@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.
12-02-2014 06:04 AM
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.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
12-02-2014 06:48 AM
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.
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.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
12-02-2014 07:15 AM - edited 12-02-2014 07:15 AM
@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.