I just had a report sent-in about a downstream site no longer receiving
METAR data from its upstream site. I think the situation is a good
example of the new feature that was added to LDM 6.11 and want to share
it with you so that you'll know what to do if you get bitten by this new
The situation was this: the downstream site had REQUEST entries for both
the WMO and DDS data-feeds. The DDS data-feed is a subset of the WMO
data-feed. Consequently, the upstream LDM 6.11 rejected the DDS request:
Sep 26 17:00:06 upstream-host downstream-host NOTE: [uldb.c:255]
feedtypes: requested=DDS, extant=WMO
Sep 26 17:00:06 upstream-host downstream-host NOTE: [uldb.c:1206]
Sep 26 17:00:06 upstream-host downstream-host NOTE: [uldb.c:1242]
request from downstream-host
Sep 26 17:00:06 upstream-host downstream-host NOTE: [uldb.c:1771]
entry to database
Sep 26 17:00:06 upstream-host downstream NOTE: [ldm6_server.c:335] New
upstream LDM process is disallowed
This situation is both inefficient and potentially dangerous. It's
inefficient because the DDS data-products would be sent twice (not too
bad unless the DDS request was actually for something like CONDUIT data
or the bandwidth to the downstream site was low). It's potentially
dangerous because a DDS data-product could conceivably be processed
twice -- leading to unknown or unexpected behavior.
The solution was to remove the REQUEST entry for DDS data at the
downstream site. The DDS data-products are included in the WMO
data-feed, so nothing will be lost.
Having non-overlapping REQUEST entries has always been something that
was strongly recommended but never enforced. The addition of the new
anti-denial-of-service feature means that mis-configured LDM
configuration-files will now be caught.
You should check your LDM configuration-file for overlapping requests to
the same upstream LDM.
Please send any questions to <support-ldm@xxxxxxxxxxxxxxxx>. I'll copy
them to this list if I think they're of general interest.