Is there a software avail or a process that will monitor two ports and if there is no traffic close them so the program that is using them can reuse them? I talked to the vendor and they told me I needed to do this on the NAT/Firewall , but I dont see anything like that on my router. So any suggestions ideas?
thanks, Ryan Nichols
Ryan Nichols wrote:
Is there a software avail or a process that will monitor two ports and if there is no traffic close them so the program that is using them can reuse them? I talked to the vendor and they told me I needed to do this on the NAT/Firewall , but I dont see anything like that on my router. So any suggestions ideas?
Can you elaborate some more on the application in question and the problem you are experiencing.
Typically network applications reuse the ports they are registered on, and if they didn't the only way to reuse them would be to kill and restart the process, so it may be that that isn't the problem after all, but more information is needed.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
Ross S. W. Walker wrote:
Ryan Nichols wrote:
Is there a software avail or a process that will monitor two ports and if there is no traffic close them so the program that is using them can reuse them? I talked to the vendor and they told me I needed to do this on the NAT/Firewall , but I dont see anything like that on my router. So any suggestions ideas?
Can you elaborate some more on the application in question and the problem you are experiencing.
Typically network applications reuse the ports they are registered on, and if they didn't the only way to reuse them would be to kill and restart the process, so it may be that that isn't the problem after all, but more information is needed.
-Ross
This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
This error will occur when the TCP connection between the Backup Server and Replication server is closed prematurely by an external force when the replication is in progress. The replication for the jobs will fail and in the StoreGrid replication server, the socket connection remains open and the replication server thinks that the replication job is still running. Please check if there are open socket connections from the backup server in the replication server.
In the next replication schedule, the application will try to reset the active status in the replication server. If the resetting of the replication active status completes successfully, then the backup server will continue the replication. In the subsequent schedule the active replication status will be reset and Backup Server should proceed replication without any issue.
In the current version , you can workaround this issue by setting the idle socket timeout value in the replication server's NAT/router setting. By doing this, the backup server idle socket connections will be automatically closed by the replication server's NAT/router. Currently there is no socket timeout value for the idle sockets in the replication server. We do have plans to do this in our future release.
As a workaround, please try restarting the replication Server once and see if still the replication is in progres
-Thats a quote from the tech support folks.. So every 12-14hrs I go into my replication server, shut down the services and restart them after the netstat shows the ports are closed.. and we carry on..
Thanks, Ryan Nichols
Ryan Nichols wrote:
This error will occur when the TCP connection between the Backup Server and Replication server is closed prematurely by an external force when the replication is in progress. The replication for the jobs will fail and in the StoreGrid replication server, the socket connection remains open and the replication server thinks that the replication job is still running. Please check if there are open socket connections from the backup server in the replication server.
...
sounds like this application should be using some form of TCP keepalives, or it shouldn't be keeping its sockets open when its not actively using them.
So you are not talking about ports, but sockets. And it seems like you need to change either the TCP keepalive or socket timeout values. This should help you: http://tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/
On Thu, Jul 31, 2008 at 2:06 PM, Ryan Nichols rnichols430@gmail.com wrote:
Is there a software avail or a process that will monitor two ports and if there is no traffic close them so the program that is using them can reuse them? I talked to the vendor and they told me I needed to do this on the NAT/Firewall , but I dont see anything like that on my router. So any suggestions ideas?
thanks, Ryan Nichols
Do some historic searching on WEB server mailing lists. Web servers have a classic problem where the "close" of a socket is a multiple step process involving both ends of the socket. Killing the process (kill -9) or even disconnecting from a wireless hot spot can leave the server system with an open socket that could last for days.... In the old days web servers would have to be rebooted to clear this. There is now a way to drop connections after a timer expires. It is a kernel param and some think it violates the TCP/IP specification ;-) so the default is off or very long.
Slightly different are NFS, ssh and rsh links that hang out until the far system comes back. But both are a failure for the cooperative shut down of the link.
I am not sure a common simple firewall/ NAT box can help this.... Cisco and others have some good documents on line...
see also CLOSE_WAIT and FIN.... in the TCP/IP specification... and look for related Linux network flags
-
D Steward -
John R Pierce -
NiftyClusters Mitch -
Ross S. W. Walker -
Ryan Nichols