LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TCP Server loses connection

Solved!
Go to solution

Do you have a massive number of connections in the CLOSE_WAIT state? That's not good.

 

You are correct that most examples put the close outside the loop, but they also put the Wait on Listener outside the loop. After the connection is established, it remains open for the duration of the program, instead of opening a new connection for every piece of data. That's the recommended approach, since there's a lot less overhead in reusing an existing connection versus opening a new one. However, that also means the sending side needs to be able to keep the connection open. If it can't do that, then you need to close the connection on the server end every time the client closes the connection on its end, otherwise you end up with all those connections in CLOSE_WAIT.

0 Kudos
Message 11 of 16
(752 Views)

@nathand wrote:

Do you have a massive number of connections in the CLOSE_WAIT state? That's not good.

 

You are correct that most examples put the close outside the loop, but they also put the Wait on Listener outside the loop. After the connection is established, it remains open for the duration of the program, instead of opening a new connection for every piece of data. That's the recommended approach, since there's a lot less overhead in reusing an existing connection versus opening a new one. However, that also means the sending side needs to be able to keep the connection open. If it can't do that, then you need to close the connection on the server end every time the client closes the connection on its end, otherwise you end up with all those connections in CLOSE_WAIT.


Okay, I see.  I'm not sure whether the connections are closing or not, when I run netstat it only has a bunch of other unrelated connections as established, but I see the connections related to this appear and go immediately to close_wait.  Either way, I guess it doesn't throw an error or anything if I close the connection after the write so it doesn't hurt to do it.

0 Kudos
Message 12 of 16
(749 Views)

The other end is closing the connection after sending data; if it kept the connection open, in netstat the connection state would remain ESTABLISHED. CLOSE_WAIT is the state when the remote side closes the connection and is waiting for the local side to do so.

 

Do you have documentation or code for the other end of the communication? Is it another LabVIEW application that you wrote, or something else? It would help to know whether it can reuse a connection instead of opening a new one every second.

0 Kudos
Message 13 of 16
(747 Views)

It's a python driver written by me and someone else to use another program in conjunction with labview/tcpip.  There's equally silly issues on that side regarding keeping the connection open.  I think the easier path is to close the connections on the labview side.  I also saw a program which monitors and closes unused tcpip connections after a certain time limit.  I could potentially use that as well.

 

Thanks for the help.

0 Kudos
Message 14 of 16
(744 Views)

@dsiap wrote:

It's a python driver written by me and someone else to use another program in conjunction with labview/tcpip.  There's equally silly issues on that side regarding keeping the connection open.  I think the easier path is to close the connections on the labview side.  I also saw a program which monitors and closes unused tcpip connections after a certain time limit.  I could potentially use that as well.

 

Thanks for the help.


Both ends of the connection should close. There are resources consumed and maintained for each connection until you actually close it.You will get an error if you try to write data to a connection that has been closed by the other end. You may not always get an error if you are simply doing reads.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 15 of 16
(724 Views)

@Mark_Yedinak wrote:

@dsiap wrote:

It's a python driver written by me and someone else to use another program in conjunction with labview/tcpip.  There's equally silly issues on that side regarding keeping the connection open.  I think the easier path is to close the connections on the labview side.  I also saw a program which monitors and closes unused tcpip connections after a certain time limit.  I could potentially use that as well.

 

Thanks for the help.


Both ends of the connection should close. There are resources consumed and maintained for each connection until you actually close it.You will get an error if you try to write data to a connection that has been closed by the other end. You may not always get an error if you are simply doing reads.


Yeah that's what I meant.  I meant close the connection on the labview side (as well as the client side) as opposed to keeping the connection open and negating this whole discussion.  

 

Thanks.

0 Kudos
Message 16 of 16
(719 Views)