Chapter 9
Nodes
9.1 Introduction
In Chapter 11, the Device Manager is introduced along with its primary role: to deploy and manage Device proxies in whatever host the Device Manager has been launched. The term Node is used to refer to the Device Manager and its associated Devices and Services.
The concept of a Device and its relationship with the deployment of a set of Components in an Application is one of the more complicated concepts in REDHAWK. A Device is a program that the Domain Manager interacts with to determine whether or not a Component can run on the host where that Device is located. If it is determined that the Device can host that Component, the Device provides the Domain Manager with the API necessary to load the Component binaries over the network and execute them. In short, the Device provides the remote host discovery mechanism to the Domain Manager and the mechanism needed to load and execute whatever Component files are needed to run the Component on the Device host.
This chapter provides a description of how to interact with Devices and Nodes using the REDHAWK IDE.
9.2 Running a Node
As part of the REDHAWK install, a Domain and Node are setup by default. To launch the Domain and Node refer to Section 11.1.1.
9.2.1 Exploring the Running Node
- In the REDHAWK Explorer View, expand REDHAWK_DEV.
- Expand Device Managers.
- Expand DevMgr_<localhost>.localdomain.
- Select GPP_<localhost>_localdomain.
- Select the Properties view tab. The Properties view displays all the Properties for this Device, such as the operation system name, amount of available memory, and other important information, as seen in Figure 9.1.
9.2.2 Creating a Component that Consumes Resources
- Create a Python Component called sample.
- On the Project View, select the Implementations tab.
- On the bottom-right of this view, the Dependencies section is visible. Click Add... on the Dependency subsection of the Dependencies section.
- In the Dependency Wizard, select Kind=Property Reference and Type=allocation.
- The Refid field is more complicated; the Component needs to be given some Property that the Component consumes when it is running on a Device. An example of such a Property is memory. For this example, memory is an attribute (Property) of the Device that the Component consumes. To describe this, click the Browse button on the Refid field and select GPP:memCapacity (do not worry if there are multiple instances of the same Property on the list, just pick one).
- After selecting this Property, the globally unique ID of the property populates the Refid field, which in this case is: DCE:8dcef419-b440-4bcf-b893-cab79b6024fb (this is the id of the corresponding Property of the GPP). To complete the dependency definition, provide a value for the consumption of this Property: in this case, set Value=1000.
- Click Finish.
- Save the project, generate the code and drag the Component project to REDHAWK Explorer > Target SDR.
9.2.3 Create a Waveform for the New Component
- Create a new Waveform called sample_deploy.
- Drag the Component sample from the Palette onto the Diagram.
- Save the project and drag the project sample_deploy from the Project Explorer to REDHAWK Explorer > Target SDR.
9.2.4 Observe the Effect of Launching the Component
- On the running Domain, select GPP_<localhost>_localdomain and note the value for memCapacity on the Properties tab for the GPP Device as seen in Figure 9.1.
- Launch the Application sample_deploy on the running Domain (right-click Domain, select Launch Waveform...> sample_deploy> Finish). Note memCapacity for GPP_<localhost>_localdomain again; it is 1000 less than before the launch of the Application.
- Release the Application (REDHAWK_DEV > Waveforms > sample_deploy_<#> right-click Release). Note memCapacity for GPP_<localhost>_localdomain again; it is restored to the original value.
9.2.5 Creating a New Node
As shown in Section 9.2.1, a Node is a Device Manager instance with an associated set of Devices and Services. A Node is completely defined by a Domain Manager Configuration Descriptor (DMD) XML file. A Device Manager uses the information in this XML file to deploy, configure, and inter-connect Devices and Services (Services are described in Chapter 8).
The REDHAWK Node Project in the REDHAWK IDE provides a mechanism for generating these DMD files. By invoking the REDHAWK Node Project, a wizard is started where the developer selects different characteristics for the Node like the project name. In the wizard, the developer must provide both a project name and a Domain Manager name. The Domain Manager name is the name of the Domain that the Device Manager automatically associates with upon startup. At runtime, the Domain Manager name that the Device Manager associates with can be overridden.
The Node project has multiple tabs. The most intuitive tab is the Diagram tab, which allows a developer to drag Devices available in $SDRROOT into the Node, as seen in Figure 9.2. Once the set of members for a particular Node is determined, save the project and drag it to Target SDR to install it.
To launch this new Node:
- Right-click the Node descriptor, Target SDR > Nodes > sample_node.
- Select Launch Device Manager. The running Node is now visible under the running Domain’s Device Managers section.
9.3 Distributed Computing and RF Devices
9.3.1 Dependencies
As described in Section 9.2.2, a Component can be described as consuming an arbitrary amount of capacity from a Device; this relationship is called a dependency. Dependencies are generalized, so it is possible to create a dependency based on attributes (Properties of kind allocation) of Devices irrespective of the specific nature of a Device.
A dependency is defined by how much of a particular Device resource is required. For example, a Component dependency could be a requirement of 1.7 units of Device Property some_id Testing this description requires the runtime environment to only determine whether a Device contains an allocation Property with the ID some_id; this concept can be generalized to any physical constraint that a Device might have, requiring only a convention between the Component developer and the Device developer regarding a Device’s Property ID and units, both of which are publicized in a Device’s PRF file (prf.xml).
9.3.2 Allocation Properties
Allocation Properties are Device Properties that are associated with an action and are used by the runtime environment to determine whether or not a Device can support a particular Component dependency. This action can either be external or some logical operation (e.g., eq (equals) or lt (less than)).
9.3.2.1 Non-External Properties
Non-external Properties are evaluated by the runtime environment without querying the Device. For example, a Component dependency on an allocation Property with operation eq might be blue. The runtime environment then checks the Device’s PRF file (prf.xml) and the Device Manager’s configuration file for the deployment of that Device (dcd.xml) to determine whether that Property’s value is equal to blue.
9.3.2.2 External Properties
External Properties, on the other hand, are handled by the Device. For example, a Component dependency on an allocation Property with operation external might be yellow. The runtime environment then makes a function call on that Device with two arguments: the allocation Property ID and the value yellow. The Device then, at its own discretion, determines whether to provide a positive response or a negative one. The algorithm used by the Device to determine whether or not it has sufficient capacity to allocate against a value of yellow is left up to the Device developer.
9.3.3 Allocation Usage
Capacity allocation can be defined at either the Component level or the Application level. When defining the capacity allocation at a Component level, that means that every time this Component is deployed, that capacity must be available. When defining the capacity allocation at a Application level, that means that every time that this Application is deployed, that capacity must be available, irrespective of which Components make up the Application.
Even though capacity allocation can be used to describe any dependency that a Component may have, in reality there are two kinds of capacities that concern REDHAWK: RF and computing.
9.3.3.1 RF Allocation
The allocation of RF capacities is with Properties that are defined as part of the FrontendInterfaces, which are described in Appendix F. It generally makes more sense to define the RF capacity allocation at the Application level rather than the Component level, since the Application understands the context for the deployment. However, RF capacity dependencies can be declared at either the Component level or the Application level.
9.3.3.2 Computing Allocation
Determining capacity for computation is different from determining RF needs. RF needs are fairly straightforward (i.e.: I need to tune to 100 MHz with a 200 kHz bandwidth). Computing resources, on the other hand, can vary substantially. A program (i.e.: a Component) consumes different amount of computing resources depending on the nature of the computing platform. Things like L2 cache size and the layout of the processor (from a NUMA perspective) can have a dramatic impact on the computational load a program has on the processor.
Due to the variability intrinsic to computing resources, REDHAWK does not rely on hardcoded estimates for the selection of a computing platform. Instead, GPP implements a reservation mechanism. When a Component is loaded onto the GPP, the GPP reserves an arbitrary, and tunable, amount of resources. GPP tracks the state of the Component, and when the Component changes state from stopped to started, the reservation is tabled, and GPP inspects the actual usage by the Component. When the state of the Component changes from started to stopped, the tabled reservation is applied again.
Using this reservation/observation behavior, Components can be automatically distributed over an arbitrary number of computers with no planning needed on the part of the user.
The user can force Components to deploy to specific GPPs. To force a specific placement, use the device assignment fields when creating the Application.
9.3.3.3 The Deployment Process
The runtime environment scans all non-busy executable Devices registered in the Domain to determine which GPP matches the processor/operating system dependency. A Device is busy when its state is returned as BUSY, otherwise it is either IDLE or ACTIVE. When a Device is found that satisfies all Component dependencies, it marks that Device as assigned to the deployment of that Component and moves on to whatever other Components make up the Waveform. Once all Components have been found an assigned GPP, the Components are deployed to all those GPPs.
9.3.3.4 Distribution of Files
All Component binaries and descriptor files reside in $SDRROOT/dom on whatever host is running the Domain Manager. In every host that is running a Device Manager, a cache directory is created in $SDRROOT/dev, with a directory entry for each Device that the Device Manager manages. When a Component runs on any given Device, the binary (or module or Java ARchive (JAR) file) is copied from $SDRROOT/dom to the Device’s cache directory. Using this mechanism, the Device can start the Component process on a remote host.
9.3.3.5 Dependency Management
A difficulty in deploying a Component is that, as a program, it might have dependencies like C/C++ libraries, Python modules, or Java JARs. REDHAWK allows for the creation of soft package dependencies, where a library, module, or JAR can be associated with its own profile. Components that have a runtime dependency with this library, module, or JAR, can declare this library profile as a dependency. When the Component is loaded over the network, this dependency is also loaded, and before the Component is forked, the Component’s local running environment is changed to include the library in $LD_LIBRARY_PATH, module in $PYTHONPATH, or JAR in $CLASSPATH. The allocation/dependency requirements associated with the Component are also applied to the library; for example, if a Component is designed to run on an x86_64 platform, the runtime environment checks that dependency runs on an x86_64 platform.

REDHAWK Documentation is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.