Changes between Version 6 and Version 7 of Internal/OpenFlow/Controllers/MultiCtl/FLInternals

Timestamp:

Sep 9, 2012, 6:43:16 PM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/Controllers/MultiCtl/FLInternals

@@ -2 +2 @@
 This is a quick recap/overview of the internal workings of !OpenFlowHub's Floodlight !OpenFlow controller. There is a good amount of official documentation at openflowhub.org; the contents of this page are side-notes compiled based on some code reading done in 2012.
 
-As a convention, classes and interfaces are shown in `terminal type`, and methods and variables in ''italics''. 
+As a convention, classes and interfaces are shown in `terminal type`, and methods and variables in ''italics''. Furthermore, "module" and "service" may be used interchangeably unless otherwise specified.  
 
-== Loading and Initialization == 
+== I. System Initialization == 
 Docs: http://www.openflowhub.org/display/floodlightcontroller/Module+loading+system
 
-Floodlight can be broken down into two main components: A module loader and all of the modules that implement Floodlight's services and functions. Initialization is therefore characterized by four main steps:
+Floodlight can be broken down into two main components: A module loader and all of the modules that implement Floodlight's services and functions. Initialization is characterized by four main steps that bring these service-providing modules up:
  1. Read in configurations
  1. Load modules
@@ -13 +13 @@
  1. Register modules with controller service  
 
-=== Loading ===
+=== 1.1 The module loading process ===
 The startup process of Floodlight begins with the reading in of configuration files and loading of necessary functional components (modules). 
 
@@ -20 +20 @@
  1. floodlightdefault.properties: a list of service-providing modules and their configurations
  
-The files are read by the module loading system to find and properly load all of the modules. Module interdependencies are found with a DFS search for dependencies of each module beginning with the service-providing ones listed in the second file. A module is anything that implements the `IFloodlightModule` interface, and this interface provides a method, ''getModuleDependencies()'', which facilitates the building of this dependency tree. the methods in the module loader that are responsible for this task are ''loadModulesFromContig()'' and ''loadModulesFromList()''. The procedure produces the smallest collection of modules to be loaded.  
+The files are read by the module loading system to find and properly load all of the modules. Module interdependencies are found with a DFS search for interdependencies beginning with the service-providing ones listed in the second file. A module is anything that implements the `IFloodlightModule` interface, and this interface provides a method, ''getModuleDependencies()'', which facilitates the building of this dependency tree by returning a list of modules that a module depends on. the methods in the module loader that are responsible for building the dependency list are ''loadModulesFromContig()'' and ''loadModulesFromList()''. The procedure produces the smallest collection of modules to be loaded.  
 
 A list of modules that come with the base controller can be found [http://www.openflowhub.org/display/floodlightcontroller/Modules here].
 
-Once the list is complete each module is activated by calling its ''init()'' and ''startUp()'' methods. ''init()'' typically initializes references to services that a module depends on, and other things that do not count on a module's dependencies being fully active; ''startUp()'' takes care of them after everyone's ''init()'' are called.     
+Once the list is complete each module is activated by calling its ''init()'' and ''startUp()'' methods. ''init()'' typically initializes references to services that a module depends on, and other things that do not count on a module's dependencies being fully active; ''startUp()'' takes care of actions dependent on fully active services (e.g. callback registration) after everyone's ''init()'' are called. In addition to the ordering produced by the DFS process, the division of the module startup process into two steps guarantees that modules are able to properly register with necessary services without worrying about which ones are already initialized.         
 
-=== Initialization and module registration ===
+=== 1.2 Module initialization and registration ===
 The first module to always be activated (by the virtue of being first in floodlightdefault.properties) is the `FloodlightProvider`, which provides the key service that implements Floodlight's controller functions (managing connections from switches, keepalives, event dispatch, etc). The actual implementation at the heart of the controller service is the class `Controller`, implementing the `IFloodlightProviderService` interface. When people mention `IFloodlightProvider`, they are referring to a collection of methods that are part of this interface, and when ''floodlightProvider'' is referenced it is usually an instantiation of `Controller` (or some other implementation of `IFloodlightProviderService`).