Look for the release of LDM 6.4 in early July. Important features of this release
include the following:by Steve Emmerson
Look for the release of LDM 6.4 in early July. Important features of this release
include the following:
Until now, LDM users have almost been required to use the well-known LDM port, 388. This had two drawbacks:
LDM 6.4 users will be able to specify the LDM port to be used when building the LDM package or when executing the LDM. Additionally, REQUEST entries in the LDM configuration-file can specify what port to use. For example
REQUEST ANY .* idd.domain:388
LDM releases prior to 6.4 contain a loophole by which data-products could be missed during any reconnection to an upstream LDM for an aggregated feedtype. In an aggregated feedtype, the order in which data-products were inserted into the product-queue was not necessarily the order in which they were created.
The solution is for a downstream LDM 6.4 to encode in its data-product request the signature (i.e., MD5 checksum) of the last, successfully-received data-product. This is done in a way that is backward compatible with pre-6.4 LDMs and yet allows an upstream 6.4 LDM to start sending data-products from its product-queue exactly where it left off when the disconnection occurred.
Releases prior to 6.4 had no way to prevent a downstream LDM from requesting all data-products in a given feedtype. This made it difficult for upstream sites to control the data-products being sent to downstream sites.
With LDM 6.4, two additional (but optional) fields have been added to the ALLOW entry. The first additional field is an extended regular expression that product-identifiers of data-products must match in order to be sent downstream. The default for this field is “.*”, which obtains pre-6.4 behavior (so the configuration-file needn't be modified unless this new feature is desired). The second additional field is an extended regular expression that product-identifiers must NOT match in order to be sent downstream. If this field is absent, then this test is disabled.
A contrived example is
ALLOW IDS|DDPLUS \.COM$ ^SAUS ^SAUS4
Effectively, this removes the limitation on the number of data feeds imposed by the 32-bit feedtype mask. Users may create new feeds under the EXP feedtype and then manage their dissemination based on the above mechanism and wisely-designed product-identifiers.
Downstream LDM's prior to version 6.4 could be statistically configured to received data-products in PRIMARY mode (i.e., using HEREIS messages) or in ALTERNATE mode (i.e., using COMINGSOON and BLKDATA messages). This meant that the users had to decide between bandwidth usage and reliability when configuring their LDM system. Two PRIMARY feeds resulted in increased reliability – but at double the bandwidth. On the other hand, one PRIMARY feed plus one ALTERNATE feed used much less bandwidth but could be unreliable--especially if the electronic distance to the ALTERNATE upstream LDM was significant.
With LDM 6.4, the first downstream LDM of a given feedtype and pattern will, initially, use the PRIMARY receive-mode. All other downstream LDM-s with that same feedtype and pattern will, initially, use the ALTERNATE receive-mode. Each downstream LDM will check, however, its success-rate at inserting data-products into the product-queue. If an ALTERNATE-mode downstream LDM discovers that it's primarily responsible for inserting data-products, then it will disconnect and re-establish the connection in PRIMARY-mode. Similarly, a PRIMARY-mode downstream LDM that discovers it is no longer primarily responsible for data-product insertion will reconnect in ALTERNATE-mode.
This means that an LDM site can request data from two different upstream LDM sites--with negligible concern about bandwidth and then never have to worry about "failing-over" again if one of the upstream sites goes offline.