[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[TIGGE #OHX-952032]: LDM connection timeout

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [TIGGE #OHX-952032]: LDM connection timeout
  • Date: Mon, 12 Feb 2007 10:14:51 -0700
Manuel,

> The report of our network people talked about 20 new connections created
> per minute. This corresponds to the 20 REQUEST for CMA's data we have in
> our ldmd.conf file. So I guess it is the ones receiving data from CMA.

When trying to connect to an upstream LDM, each downstream LDM started as
a result of a REQUEST entry does the following: if the attempt fails, then
it destroys its side of the connection, sleeps, and then tries to connect.
The sleep duration starts at one second and then geometrically increases
after each unsuccessful attempt up to a maximum duration of 30 s.  Once
the maximum duration is hit, then the downstream LDM will try to connect
every 30 s.  Even with 20 downstream LDM-s, this should be very far from
a denial-of-service attack, where connection rates are hundreds of times
per second.

Because the downstream LDM completely destroys its side of the connection
before attempting another, the TCP layer should ensure that the TCP
connection is truly gone.

What do your network administrators mean when they say that the LDM
connections don't time-out?  What, exactly, are they seeing?

If you want to examine the code, look at file "src/server/acl.c", function
"prog_requester()".  You'll see how the connection attempts and sleep
intervals interact.  The function "req6_new()" attempts to connect using
LDM-6 protocols.

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: OHX-952032
Department: Support IDD TIGGE
Priority: Normal
Status: Closed