Changes between Version 14 and Version 15 of Internal/OpenFlow/Controllers/FloodLight

Timestamp:

Jun 5, 2012, 2:43:32 PM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/Controllers/FloodLight

@@ -110 +110 @@
  1. the core, which listens to !OpenFlow messages and dispatches events, and
  2. various modules which handle the events 
-In general, events encompass a range of things, including a switch joining/leaving the network, the reception of a !OpenFlow message e.g. a PACKET_IN, and the controller's role changing. 
+In general, events encompass a range of things, including switches joining/leaving the network, reception of !OpenFlow messages e.g. PACKET_INs, and the controller's role changing. 
 
 === Listeners, Modules, and registration ===
@@ -122 +122 @@
 A module always implements the first interface, but may implement one or both of the latter two as ''listeners''. For example, The REST API module (interested in everything under the sun) implements both, while the Hub module (interested in just PACKET_INs) only implements `IOFMessageListener`.
 
-Class `Controller`, Floodlight's core controller implementation, dispatches events to the modules by calling the modules' event handling functions, namely ''receive()''. The controller keeps mappings of which modules implement which listener in two map structures, ''switchListeners'' and ''messageListeners''. These maps are used by the controller to dispatch the events to the proper listeners. `IFloodLightProviderService`, the interface that `Controller` implements, in turn provides two functions, ''addOFSwitchListener()'' and ''addOFMessageListener()'', which the modules can call in their initialization functions to add themselves to the appropriate map. The controller's listener maps are populated at startup, when the module loader initializes each required module.  
+Class `Controller`, Floodlight's core controller implementation, dispatches events to the modules by calling the modules' event handling functions, namely ''receive()''. The controller keeps mappings of which modules implement which listener in two map structures, ''switchListeners'' and ''messageListeners''. These maps are used by the controller to dispatch the events to the proper listeners. `IFloodLightProviderService`, the interface that `Controller` implements, in turn provides two functions, ''addOFSwitchListener()'' and ''addOFMessageListener()'', which the modules can call in their initialization functions to add themselves to the appropriate map. 
 
 === Startup ===
@@ -132 +132 @@
 The `FloodlightModuleLoader` basically coordinates calls to the functions provided by the `IFloodlightModule` interface for each module in the config file (floodlightdefault.properties) and the modules that they depend on. Some key points are: [[BR]] 
   * The function ''loadModulesFromList()'' finds all of the modules that it needs to load via a DFS beginning with the modules listed in the config file. The search is facilitated by `IFloodlightModule` functions such as ''getModuleDependencies()'' (e.g. the modules themselves specify their dependencies).
+  * likewise, this function calls each module's initialization function, populating ''switchListeners'' and ''messageListeners'' in the controller. 
   * The structure ''moduleSet'' will ultimately contain the minimum number of modules that need to be loaded at startup. 
   
@@ -147 +148 @@
 Updates include switches joining and departing, controller role change, and controller IP change. The definitions are found as inner classes implementing `IUpdate`, within class `Controller`.
 
-==== !OpenFlow message processing chain ====   
+=== !OpenFlow message processing chain ===   
 The manner in which a control message is processed is defined in the modules themselves through the `IOFMessageListener` interface's ''receive'' function.