Chi, Steve Chiswell wrote:
The netstat listing that you showed with several LDM connections in time_wait may mean somethng to Steve Emmerson and/or Mike Schmidt, so I'll see if they have any imput as well as suggestions on TCP tuning.
> tcp 0 0 ldm1.woc.noaa.gov:388 atm.cise-nsf.gov:61678 TIME_WAIT > tcp 0 0 ncepldm.woc.noaa.go:388 flood.atmos.uiuc.:48265 TIME_WAIT
The "netstat" output indicates that LDM processes on hosts atm.cise-nsf.gov and flood.atmos.uiuc established TCP connections to the LDM server on the local host (alias ldm1.woc.noaa.gov and ncepldm.woc.noaa.go) and that the corresponding LDM process on the local host closed the connections. See <http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html>.
I can imagine several situations in which this would occur. The first is when the remote hosts are not allowed to connect -- in which case the top-level LDM server on the local host would close the TCP connection. Check the LDM configuration-file, etc/ldmd.conf, to ensure that both atm.cise-nsf.gov and flood.atmos.uiuc are allowed to connect. You could also put the top-level LDM process on the local host into verbose logging mode (see <http://www.unidata.ucar.edu/software/ldm/ldm-current/basics/logfile-format.html>).
Another situation is when a downstream LDM is not allowed to received the data that it is requesting. In this case, the upstream LDM process on the local host should log a warning-level message.
The last situation is when an upstream LDM process on the local host tries to send an RPC message to the downstream LDM for which it expects a reply and the wait for the reply times-out. Again, the upstream LDM process should log a message.
Regards, Steve Emmerson