•         advanced

LDM 6 Behavior

This page describes the behavior of the LDM 6 program.

Contents

• Top-level rpc.ldmd behavior
• Upstream LDM 6 behavior
• Downstream LDM 6 behavior

Top-level rpc.ldmd behavior

When executed, the rpc.ldmd program does the following:

1. If the LDM logfile is not standard error, then the program forks itself and the parent process terminates. The child process detaches itself from the process group of the parent process and becomes a process group leader.

2. Initializes logging and logs a "Starting Up" message.

3. Establishes an Internet port that will be used for incoming connections. If the program is set-uid-root, then the port number will be 388; otherwise, the port number will be decided by the operating system.

4. Registers the LDM 5 and LDM 6 services with the RPC portmapper (if it is available) using the port number from the previous step.

5. Reads the LDM configuration-file, ldmd.conf, and does the following:

   • Adds all ALLOW and ACCEPT entries to internal databases.

   • Executes all programs specified in EXEC entries as asynchronous child processes.

   • Forks an asynchronous copy of itself as a downstream LDM for each REQUEST entry.

6. Goes into a loop in which it alternately

   • Accepts the termination of any child processes; and

   • Listens on the previously-established port for incoming connections from other LDMs. When a connection is made, the program does the following:

     1. Validates the other LDM against the internal database of ALLOW and ACCEPT entries. If the LDM is not allowed to connect, then the connection is terminated; otherwise,

     2. Forks an asynchronous copy of itself to service the connection. The child process will be an upstream LDM if the first incoming message is a FEEDME or NOTIFYME; otherwise, if the first incoming message is a HIYA, then the child process will be a downstream LDM.

Upstream LDM 6.6 behavior

An upstream LDM does the following:

1. Computes the intersection of the data-product selection-criteria contained in the FEEDME or NOTIFYME request and the criteria specified in the relevant ALLOW entry.

2. If the intersection is empty, then then connection is closed and the process terminates; otherwise,

3. If the intersection is not empty but also not equal the the original request, then the process informs the downstream LDM about the intersection and continues to listen; otherwise,

4. The process acknowledges the request and begins sending matching data-products from the product-queue to the downstream LDM using the primary or alternate transfer-mode (for FEEDME requests) or NOTIFICATION messages (for NOTIFYME requests).

5. If the process reaches the end of the product-queue, then it suspends itself for 30 seconds or until reception of a SIGCONT signal (from an ingester or downstream LDM) whichever occurs first.

6. If nothing has been sent to the downstream LDM in 30 seconds, then the process sends a NULLPROC message.

Downstream LDM 6 behavior

A downstream LDM does the following:

1. Sets the initial data-product selection-criteria. The initial "start" time is set as follows:

   • If a "time offset" option was specified on the rpc.ldmd command-line, then the "start" time is set to the current time minus the specified time offset; otherwise,

   • The "start" time is set to the current time minus the value of the "maximum latency" option (default: 1 hour).

2. Obtains the metadata of the most recently-received data-product corresponding to the data-product selection-criteria. If the home-directory of the LDM user contains a metadata file corresponding to the data-request and the upstream LDM, then the metadata in that file is read and used; otherwise, the metadata of the most recent data-product in the product-queue that matches the data-product selection-criteria is used.

3. Encodes into the data-request the data-product signature of the metadata from the previous step, if available, so that the upstream LDM can start sending data-products from where the previous downstream LDM left off.

4. Enters a loop that terminates when a successful FEEDME request is made to the upstream LDM:

   • Makes a FEEDME request to the upstream host specified in the REQUEST entry using the current data-product selection-criteria. If the REQUEST entry is the first one with that specific feedtype/pattern pair, then the connection will use the primary transfer-mode; otherwise, the connection will use the alternate alternate transfer-mode.

   • If the upstream LDM replies with a more restrictive data-product selection-criteria, then the processs uses that for the current data-product selection-criteria.

5. Receives data-products over the connection contained in HEREIS or COMINGSOON and BLKDATA messages. When the product has completely arrived, it is inserted into the product-queue and a SIGCONT signal is then sent to the LDM process group. The data-product creation-time is used to update the "start" time in the current data-product selection-criteria.

6. If nothing has been received in 60 seconds, then the process connects to the top-level rpc.ldmd on the upstream host and uses an IS_ALIVE message to inquire whether or not the relevant upstream LDM process is still running:

   • If the upstream LDM terminated, then the process closes the connection and returns to step 2, above; otherwise,

   • The process continues to wait for data-products.

Contact Us   •   Site Map   •   Search   •   Terms and Conditions   •   Privacy Policy   •   Participation Policy

Unidata is a member of the UCAR Office of Programs, is managed by the University Corporation for Atmospheric Research, and is sponsored by the National Science Foundation. P.O. Box 3000   •   Boulder, CO 80307-3000 USA   •   Tel: 303-497-8643   •   Fax: 303-497-8690