Ethernet Data Transfer Fails on Deployed RT Application

Question

I have written a TCP/IP client that interacts with a custom TCP/IP server over a very local network (one cable). I've been developing this for a couple of months on LabVIEW 2014 (not SP1) targeting a cRIO9068 chassis.
Development went very smoothly, never any flaky Ethernet problems on the LabVIEW side. Once I got it all bulletproof I deployed and went out to the plant. 
At the plant, Ethernet will connect but no data is transferred. Puzzled, I reconnected my LabVIEW development machine to the chassis, opened the project from which the application was deployed and ran it from inside the project. It works. I see this behavior on the original chassis too, so I have two chassis that work with the development environment but do not work when deployed.
What's up with this? Any ideas appreciated, I can find nothing on this subject in these forums or a general Google search.
Thanks,
Bill

Answer 1

The problem was caused by the Execution setting of the top-level VI being set to reentrant. I set it to non-reentrant.
The key was using 
netstat -a
I saw that the application had multiple ESTABLISHED connections where only one should be possible.
Along the way I cleaned up my code a bit, but the root cause was multiple instances of the application running on the cRIO. If the startup vi is reentrant then you get an instance when the hardware starts or restarts, then you get another instance when you fire up the web-based front panel. Instead of the panel connecting to the running program another one is started.
When running from the development environment this does not happen. The development environment enforces single execution on the top-level vi. 
A shout-out to the NI software people: A little warning: "Multiple instances of the program may run because the top-level VI is reentrant" when the build starts, plus adding to the panel documentation something like "Connecting a web-based remote panel to a reentrant top-level VI will invoke a second copy of the top-level VI" would have saved me a day...
Cheers,
Bill