Component Partitioning

The following figure illustrates OpenRG's component partitioning.

Figure 15.2 Component Partitioning

15.3.1 Coordination Logic

OpenRG is a multi-threaded multi-process product. There are many kernel threads, as well as user mode processes.

The logic of the OpenRG management code (called openrg) is handled by Main Task. Main Task is a framework for running entities that provide services, and for controlling network devices. It is responsible for system initialization, reconfiguration, and communication of the reconfiguration events with the various entities, which in turn correspond with the functional tasks. Main Task is also responsible for coordinating dependencies between entities and network devices. For example, it coordinates between a DSL PPP link and a dependent underlying ATM device. Main Task is single-threaded. This characteristic has the following advantages:

• Synchronization issues between processes/threads are avoided. Tasks cannot be interrupted while processing—only when waiting for a callback.

• Context switches are minimized.

• Inter-Process Communication (IPC) is simplified—functional tasks communicate with the Main Task using a simple function call. Conversely, an ordinary multi-process design involves information packaging, IPC tunneling and parsing by the receiving side.

• Memory footprint is reduced by linking all of the modules together, eliminating the code needed for IPC, configuration and synchronization.

At the heart of the system lays the event loop. Main Task is designed as an event-driven application. Events are expired timers, network events (ready to read or write on a file

descriptor) or an exception. Each component registers its own handlers for various events; this is usually done upon startup. Since events are used throughout the system, this does not appear explicitly in Figure 15.2. The Coordination Logic is divided into 2 parts:

• Generic – Always exists. The major generic part is the Entities mechanism, which serves as a uniform API between tasks and the core logic of the Main Task. Each registered entity is notified upon configuration changes, and may affect other entities. For more information, refer to Section 15.3.1.1.

• Component Specific – Belongs to specific components. For example, the TOD client entity, which is a part of the TOD client component, notifies the DHCP Server when a new time is received, so that it can update its lease status. Most components register themselves as an entity. Therefore, they are notified on configuration changes. For more information, refer to Section 15.3.1.2.

The following figure demonstrates the Main Task's core logic.

Figure 15.3 Main Task's Core Logic

15.3.1.1 Entities

An entity serves as a unified API between a task, the core logic of the Main Task, and the Configuration Database. An entity supports the following operations:

• open – The entity registers itself, so that it will be called on relevant events. In most cases, this operation is also responsible for task initiation.

• changed – When rg_conf is modified, the entity must find out if there is an impact on its managed tasks.

• reconf – The entity should reconfigure its tasks based on the old and new values of rg_conf.

• close – The entity should shut down its tasks.

For example, the DNS entity handles the DNS task according to OpenRG's rg_conf

configuration database. This entity initiates the DNS task, and equips it with callback functions

that enable the task to search for locally configured host names. These names are entered either manually by the user using the Web-based management, or by the DHCP server, which dynamically allocates IP addresses to computers on the network.

The architectural advantage of this design is that the task is unaware of the configuration database format, nor of the methods of polling the DHCP server for a host name—all of these responsibilities are left to the entity.

15.3.1.2 Tasks

A task is a set of functions that implement a certain protocol or service, for example PPP, DNS or HTTP. A task can be characterized as being self-contained and system independent. It does not rely on other tasks, configuration files or another kind of outside help.

The OpenRG library, libopenrg, provides the task with rudimentary services such as an event dispatch loop, memory allocation and logging functions. The entire configuration that a task may require is imparted as parameters to its open() function. The task's genuine work is actually performed by the callback function, a pointer which is also given as a parameter to the open() function. It means that tasks are inherently portable and reusable. To illustrate, the Ping task can be employed in two different ways:

• The DHCP server may use the Ping task to test whether an IP address, it is about to lease, is already taken by pinging the address in question. The task parameters in this case will be a ping packet, a brief time-out reply and callback functions. All of these are implemented in the DHCP code.

• The Web-based management may use the Ping task to implement a 'Connectivity

Diagnostics Test' interface screen. The task parameters will be the number of ping attempts, a ten second time-out and callback functions. Again, these parameters are implemented in the Web-based management code.

15.3.2 Configuration Database

Configuration Database is used by all components to store information and various system settings. Throughout this book, the term rg_conf will be used to refer to the configuration database. For more information about the configuration database, refer to Chapter 18.

15.3.3 Devices

Devices are used to manage networking devices. Components that implement networking devices register handlers for the new device type. For more information about devices, refer to Section 15.4.

15.3.4 System Services

System Services include the following:

• Error Logging (rg_error) – A general logging mechanism. Each component may use the rg_error functions to log events, similar to the standard syslog() function. Some components register themselves in rg_error, and they are called later for each event report. For example, email notification is implemented by registering a mail function as its handler.

• Language Support – A general mechanism that allows dynamic language change. It is used by components wishing to display text to the user, typically in WBM pages. Each component may use the language support by registering a table of all strings in each of the supported languages. For more information, refer to Section 28.6.

• Inter-Process Communication (IPC) – Used for communication between the OpenRG process and other processes. For example, an L2TP daemon uses IPC to check the password of a specific user. IPC is implemented by listening on a predefined TCP port on lo interface;

interested processes need to use either ipc or mgt_client libraries to send commands to the main process and receive the results.

15.3.5 Management Tasks

The management tasks export interfaces that allow monitoring and control from outside. Each component that wishes to be managed registers its own management functions in each of the management components. The following management components are defined:

• Web Based Management (WBM) – The main management method. It allows the user to control OpenRG using a web browser. Each component registers functions to display WBM pages and receive user inputs. Some pages are system-wide (e.g. login page) and are registered as part of WBM initialization, and others are component-specific (e.g. File Sharing) and are registered as part of the component initialization. For more information, refer to Chapter 28.

• Command Line Interface (CLI) – Used by the command-oriented management: console, telnet, ssh, remote management and JNET. Each component that wishes to be managed registers its own management functions (that will be called when the associated command string is requested) in the CLI component. Each component that wishes to manage OpenRG using CLI can use the CLI component to perform the requested commands. For more information, refer to Chapter 27.

• TR-069 – A CPE WAN Management Protocol. Each component registers parameter get and set functions, which will be called when the ACS issues a parameter get or set command, respectively. For more information, refer to Chapter 37.

• UPnP IGD/TR-064 – LAN side management protocols. These protocols have a predefined set of actions, which are already implemented, and use the generic devices interface and the firewall. For more information, refer to Chapter 38.

• SNMP – Implements its operation through the use of generic MIB structures. Each component implements its specific MIBs and adds the MIB structure to the SNMP agent.

For more information, refer to Chapter 26.

15.3.6 OpenRG Components

Other (non-core) components comprise a set of the OpenRG tasks. Each of these tasks is responsible for a specific functionality. For example, OpenRG's DNS Server component implements the DNS server functionality. The non-core components consist of the following:

• Task – Implements the functionality.

• Entity – Used for communication with the core logic of the Main Task.

• Management – WBM, CLI, etc.

• Configuration Database – API to rg_conf

• Kernel modules – Used primarily for interfacing with the kernel and/or hardware.

However, none of these parts are obligatory. For more information about components, refer to Part IV.

15.3.7 Kernel

The kernel can be either a modified Linux kernel or VxWorks. Note that some components depend on the Linux kernel functionality, and therefore do not work in VxWorks.

15.3.8 KOS/KNET

The KOS/KNET layer is an OS abstraction layer, allowing the kernel code to be reused with multiple operating systems. For more information, refer to Chapter 23.