NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Sebastien, > as I'm one of the persons of the networking team I'll answer you directly. > I fully agree that 20 connections per minutes should be easily handled > by our firewall and network. We were just surprised to see 10000 > connections in our firewalls connection table yesterday and we wanted to > make sure that the LDM software includes all necessary mechanism to > throttle the connection rate in an anormal situations (which is the case ). 10000 connections is a large number. Were most of them due to the LDM? > Anyway is the 30 second retry limit a hard coded value and could it be > changed (without unnecessary risks)? The sleep-duration limit is hard-coded. 30 seconds was chosen because that value was similar to other hard-coded values (e.g., 35 second time-out for reading from a TCP connection by a server). The value is set in the file "src/protocol/globals.c". Because the value also determines other things (such as how long a downstream LDM will wait without receiving anything before asking the upsteam LDM server whether or not its corresponding upstream LDM process is still alive) it would probably be better to modify the use of the value as a sleep-duration limit in the file "src/server/acl.c", function "prog_requester()". For example, the lines if (sleepAmount > interval) sleepAmount = interval; could be replaced with if (sleepAmount > 2*interval) sleepAmount = 2*interval; This would result in a downstream LDM eventually trying once every minute to reconnect to an upstream LDM and could be tried without any undue risk. Regards, Steve Emmerson Ticket Details =================== Ticket ID: OHX-952032 Department: Support IDD TIGGE Priority: Normal Status: Closed