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

[IDD #TXI-514355]: LDM problem from tornado.geos.ulm.edu

Hi Hsie and Adam,

> We need some help here.  Adam, you probably need to open port 111 for
> rainbow.al.noaa.gov.  As far as I unserstand it, the new version of LDM
> can run on any port.

Just so you know, the LDM has been able to run on any port for many years.
The default port is 388.  Use of other ports was always enabled by use
of the portmapper (port 111).  In the newer versions of LDM-6, one can
specify the port that the LDM will listen on, but the default remains

> You need a RPC call to portmapper to find out
> which port the LDM server is using.  If I am wrong, please correct me.

The portmapper is not needed as long as the firewalls for the upstream
and downstream hosts are configured to be bidirectionally open for
LDM traffic.  Keeping the portmapper port (111) closed is typically
_good_ for security.

After reviewing the past several exchanges, I believe I understand what
is going on.  ULM's machine, tornado, is configured to redundantly
request FNEXRAD data from two upstream hosts.  Since tornado is running
a recent version of LDM-6, 6.4.5, it will autoswitch its feed request
mode from its upstreams based on the percentage of products it is getting
from those upstreams:  if more than 50% of products in a feed are received
from host A and inserted into the downstream queue, then the request to the
upstream will be promoted, if necessary, to PRIMARY.  Correspondingly, if less
than 50% of the products received and inserted into the downstream queue come
from upstream host B, the feed request will be depricated to ALTERNATE.
The net effect of the downstream changing its feed request to the upstream
is a breaking of its connection and reestablishing of a new one.  The result
of breaking a connection will be an entry in the upstream's ~ldm/logs/ldmd.log
file.  This explains why Adam is receiving data fine, while Hsie is seeing
error messages in his LDM log file.  I believe that the beta LDM version has decreased the verbosity of logging of connection breaks and
reconnects, but I will need to check with Steve Emmerson, our LDM developer,
to make sure.

Please let us know if you have questions on the explanation above.


Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
Unidata HomePage                       http://www.unidata.ucar.edu

Ticket Details
Ticket ID: TXI-514355
Department: Support IDD
Priority: Normal
Status: Closed