Changes between Version 2 and Version 3 of Internal/OpenFlow/Controllers/MultiCtl/FLInternals


Ignore:
Timestamp:
Sep 7, 2012, 7:14:20 AM (12 years ago)
Author:
akoshibe
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Internal/OpenFlow/Controllers/MultiCtl/FLInternals

    v2 v3  
    11= Floodlight Controller Internals =
    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; these are side-notes compiled based on some code reading done in 2012, and are not only pretty dense but also may contain errors.     
     2This 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.
    33
    44As a convention, classes and interfaces are shown in `terminal type`, and methods and variables in ''italics''.
    55
    66== Loading and Initialization ==
    7 Refs: http://www.openflowhub.org/display/floodlightcontroller/Module+loading+system
     7Docs: http://www.openflowhub.org/display/floodlightcontroller/Module+loading+system
    88
    99Floodlight 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 three main steps:
     
    2020 1. floodlightdefault.properties: a list of service-providing modules and their configurations
    2121 
    22 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. 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.     
     22The 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. 
     23
     24A list of modules that come with the base controller can be found [http://www.openflowhub.org/display/floodlightcontroller/Modules here].
     25
     26Once 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.     
    2327
    2428=== Initialization and module registration ===
     
    4751 * `Hub` is interested in receiving !PacketIns whenever `Controller` receives them from a switch, so it registers itself as a IOFMessageListener in `startUp()` 
    4852
    49 ''startUp()'' is also where service-specific variables in floodlightdefault.properties will be used to do per-module configurations. A module accesses the contents of the file through `FloodlightModuleContext` via the method ''getConfigParams()''. 
     53''startUp()'' is also where service-specific variables in floodlightdefault.properties will be used to do per-module configurations. A module accesses the contents of the file through `FloodlightModuleContext` via the method ''getConfigParams()''.
     54[[BR]] 
     55
     56modules are loaded and initialized, Floodlight will begin listening for incoming connections from switches and sending out LLDP messages to gather topology information.