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.
Brice, > What I meant by mirror and reversed was this - > > Request FT4 "^WT|^RW|^JS|^LR" > Request FT4 "^LR|^JS|^RW|^WT" Palindromic patterns. Cute! > That seems to work - no terminations since this morning. I'll get Richard to > try the 'client name' concept and let you know how it works. > > I'm still puzzled by the other obsolete entries with the 'direct-connect' > clients. There in an environment that I don't have administrative access > to... yet. So I haven't changed them yet to try anything. How 'deep' does > the 'same server' check go? I wouldn't think it would break on servers > coming out of the same network, but that is the symptom. The server-check by the LDM is on the IP addresses: requests from the same IP address are considered to come from the same downstream host. If your 'direct-connect' clients are behind a NAT, then that would explain the behavior you're seeing. > I should have access to those clients and be able to restructure them. If > you get tired of this, just point me to the module that does the checks and > I'll figure it out. Currently we still have the source on one of our > servers. In the future though, we are looking at installing via RPM and it > doesn't include the LDM source. May have to keep a copy around in my hip > pocket. The source is (as will likely be for quite a while) on GitHub. The relevant file is "ldm_server.c". Search for the string "Reduce". > Anyway, I'll let you know what else comes up. Please do. > Brice Regards, Steve Emmerson Ticket Details =================== Ticket ID: BIG-900661 Department: Support LDM Priority: Normal Status: Closed