TCP Server loses connection

[dsiap]

Hi,  I tried searching for this and didn't find the exact problem, although I have some trouble describing it.

First off what I am doing is simple data acquisition  with a couple photometers, occupancy sensors and thermocouples.  I have these set up on a central computer and I'm using labview to send the data to a tcp port and from there another program takes the data using sockets and stores it on a remote computer.  

The problem is that after a few hours the central computer with all the instrumentation seems to drop from the network.  A weird thing is that it only seems to happen with the photometer measurements, which are simple analog voltage readings, and not the thermocouples - or at least this is how it's been over a couple days.  The central computer is still relatively responsive and can be pinged, but has no internet and the data cannot  be harvested (socket.receive does not work).  I've disabled all firewalls and antivirus interference I could think of.

Any ideas?

Edit:  My bandaid fix has been to put the photometers on a more powerful computer than the central computer as it may be a resource issue?  I'm also babysitting both in the interim until I can get a real fix.

[JÞB]

windows power options?

[dsiap]

Nope, I have them set to not sleep.  Even if that were the case I just saw it happen with the thermocouples in front of my eyes.  It took awhile longer, I'm not sure if that's because of how the daqmx takes the temperature readings vs voltage readings or if because there are less thermocouples on that board then photometers on the other.  It could be the daq used as well.  Either way, they both seem to go out, althought it's been about 4 hours now and the more powerful machine seems to have no issue, it may be that I guess?  They're also different labview versions 8.5 vs 2011.  I guess if it stays up for multiple days I can either update the old version or migrate the daq to the new computer.  Still workarounds though, not quite sure how to diagnose the problem.

[dsiap]

Actually take out the whole thermocouple vs photometer part of this, it seems tied to the machine as opposed to sensor.

I'm just using TCP blocks as below.

[Mark_Yedinak]

What are your timeout values? How are your clients connecting? Also, you aren't closing your connection when completed. Each time a client connects you should close the connection once everything has been completed with that client. I do not see any TCP close for the connection ID in your code.

[johnsold]

You have not shown the DAQ part or even described the DAQ communication process. Is the DAQ in cards inside the computer, PXI, USB, something else? Are the DAQ Reads in the same loop as the TCP writes?

The reason for this line of questioning is that I am wondering if the problem is not the TCP but something else in that loop that stalls the loop.

You mentioned that the computer can be pinged when the probelm is occuring.  That indicates that the Ethernet port is functional.

Have you put an indicator on the error wire insde the loop to see if any TCP errors have occurred? Also try an indicator on the iteration terminal to verify that the loop is actually running.

Lynn

[dsiap]

I use DAQmx with the 6221 in the pci slot with a scb 68 as well as a 6009 in the usb slot.  The daq read is the thicker number wire there, it's pretty plain jane I didn't put it because the system is still reading the values and displaying the charts accurately when the tcp connection is not fucntioning.  On previous iterations of this program I did wire the error handling, I didn't see anything, I'll put them back in and see if I do.  

edit: Is the TCP part wired properly?  The connection id is closed at the end there as wired.  The other program I'm using opens and closes a new connection on a per secondish basis as that is the most reliable method we have.  It seems that a more powerful computer has solved this issue, could cleaner programming do it?  I'm attaching a bigger screenshot.

Thanks

[JÞB]

I'm wonerding if you are filling a buffer on the slower machine and overlooking an error.  Get the errors on shift registers and exit on error

[nathand · Accepted solution]

As Mark mentioned, you're not closing your connections. The operating system can only maintain a certain number of connections, and once you reach that number it won't accept any more until you close the existing ones. Each time Wait on Listener returns a new connection, that's one connection created that you need to close when communication completes. Instead you're dropping the reference to it, such that there's no way to close it. The way you have this written, you need to close the connection inside the loop, and then close the Listener after the while loop completes.

That said, are you sure this is how you want your code structured? You have to accept one connection on each of 7+ ports before you accept another connection on any of those ports. It's an unusual arrangement.

[dsiap]

@nathand wrote:

As Mark mentioned, you're not closing your connections. The operating system can only maintain a certain number of connections, and once you reach that number it won't accept any more until you close the existing ones. Each time Wait on Listener returns a new connection, that's one connection created that you need to close when communication completes. Instead you're dropping the reference to it, such that there's no way to close it. The way you have this written, you need to close the connection inside the loop, and then close the Listener after the while loop completes.

That said, are you sure this is how you want your code structured? You have to accept one connection on each of 7+ ports before you accept another connection on any of those ports. It's an unusual arrangement.

---

So you're saying I should move the close connection block inside the while loop?  Hm, the examples are not wired like that I simply adapted them to what I need.  I can try it.

Right now today it's been running for 7 hours, at once a second that's over 25000 connections, I wonder at what point it maxes out at.  Running netstat from the command line, I see the connection is created then goes to close-wait after.  I think that means the server (this computer) has initiated a close?  Not sure.  Maybe it's bad that it's staying there and not going to closed?