07-29-2013 06:24 PM
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.
07-29-2013 06:37 PM
@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.
07-29-2013 06:46 PM
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.
07-29-2013 06:52 PM
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.
07-30-2013 01:16 PM
@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.
07-30-2013 01:28 PM
@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.