Simple TCP server example fails differently on cable pull

[nanocyte]

I'm running the TCP server example located here:

C:\Program Files (x86)\National Instruments\LabVIEW 2016\examples\Data Communication\Protocols\TCP\Simple TCP

I'm seeing a diffrence based on if I use my sbrio-9627 or windows as the server (other device is client). When windows is the server, I get an error 66 on the server when I pull the cable. When I use the sbrio as a server and pull the cable, the client (on windows) disconnects but if I plug the cable back in and connect back to the sbrio I see that its still running and updating the graph. Obviously the client isn't getting the updates.

Is this just an OS difference? Is there any setting to get the sbrio to behave more like windows where it detects the disconnect throwing an error 66?

[danniwithNI]

Hi nanocyte,

Is there any difference between the error handling or timeouts on the sbrio compared to your PC? Normally this is where you'd implement the logic that would cause error 66 to be thrown and your applicaiton to stop.

[nanocyte]

I'm running the same VI but simply targeting the sbRIO or the PC so it should be the same timeout. In any case, I think a timeout will only get you error 56 so I don't see how changing the timeout could matter.

[danniwithNI]

Hi Nanocyte,

Just for clarification, where in the VI are you expecting to see the error? In the Simple TCP example, the error wires are connected to a custom dialog that displays as in the screenshot below (this only hadles error 62, 64, and 66). When I ran the example on my computer, I saw a dialog like this pop up when I closed connection on either the server or client side; does this correspond to the behavior you see? Do you see the same behavior if you run the sbRIO interactively? As an added note, timeouts can be used to handle a number of different connection issues, including error 66.

[nanocyte]

Thank you for trying it out on your end.

Yes, all my tests are operating interactively.

I created an error indicator for the error after the tcp close to determine what specific error I'm seeing. I'm expecting error 66 at the server but I only see that error when running the server in windows.

I never see your dialog because the client always exits out on error 56, which is fine.

[danniwithNI]

Hi Nanocyte,

I had tried this with my PC as both client and server before, but this time I tried to replicate you behavior again using a Linux cRIO (which should mimic the OS on your sbRIO). I modified the client VI to look at the correct IP address and both VIs to show error indicators rather than the default message that comes with the example, in an effort to replicate your system as closely as possible.

What I saw was that when I used the windows PC as the server, upon disconnecting the RIO I would see error 66 on the server side and the application would stop. Then, when I used the RIO as the server, when I disconnected it I would almost immediately get error 56 from the Windows client, which also stopped the application. Is there any other logic you may have modified in your VIs that would keep the VI from stopping after an error is thrown?

[nanocyte]

Yes, I may have increased the wait times or decreased waveform sizes in my examples to slow things down a bit but I think the descrepency you are seeing is the descrepancy I was trying to illustrate. An error 56 is a pretty typical tcp error and generally not of a serious concern—you can just retry. An error 66 is typically what is used to signal that the client is no longer available. I'm wondering if the different behavior depending on the target is expected and I'm hoping I can get error 66 so I know it's time to disconnect.

[nanocyte]

Another reason I want Error 66 is it takes much much longer to get an error 56 than error 66. I modifed the code (see attached) to count how many messages were lost:

Client on Windows:

• Received: 44
• Error:56

Server on RT:

• Sent: 2501
• Lost: 2501–44 = 2457
• Error: 56

Client on RT:

• Received: 13
• Error: 56

Server on Win

• Sent: 89
• Lost: 76
• Error: 66

[danniwithNI]

Hi nanocyte,

Have you tried reducing the Timeout time to reduce the number of dropped samples? As I linked in my previous post, error 56 is often caused by error 66, so the behavior we're both seeing is not unexpected.

[nanocyte]

Per your suggestion, I modified the VIs I attached previously to reduce the timeout on the server write VIs to 0 ms and I did not see any different behavior. The server write still runs thousands of times without error after the cable pull.