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.
Hi Hsie and Adam, re: > 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 388. > 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 6.4.6.5 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. Cheers, Tom **************************************************************************** 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