Changes between Version 12 and Version 13 of Internal/OpenFlow/Controllers/FloodLight

Timestamp:

Jun 5, 2012, 6:08:50 AM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/Controllers/FloodLight

@@ -98 +98 @@
 
 == Architecture and Implementation == #arch
-This section describes the architecture and some of the implementations of the various parts of the controller. These are largely references to source code and their Javadocs. 
- * ref: http://www.openflowhub.org/display/floodlightcontroller/Advanced+Tutorial
+This section describes the architecture and some of the implementations of the various parts of the controller, with focus on the controller core functions (net.floodlightcontroller.core* area of source code). This section is fairly dense, and is best referenced alongside the source code.   
+
+To start, here are some references:  
+ * Floodlight wiki: http://www.openflowhub.org/display/floodlightcontroller/Floodlight+Controller+Wiki
+ * javadocs: http://floodlight.openflowhub.org/files/javadoc/
+You can also generate the docs yourself with `ant javadoc` in your working directory. You may also want to join the [http://groups.google.com/a/openflowhub.org/group/floodlight-dev/subscribe floodlight-dev mailing list].  
+
+=== Overview ===
+
 The controller has two main components:
- * the core, which listens to !OpenFlow messages and dispatches events, and
- * secondary modules which handle the events e.g PACKET_INs.
-The secondary modules register with the core module when the controller is starting up. They do everything from recording certain aspects of flows to providing a RESTful API to modifying the flow tables within switches. They may also export services to leverage other modules, such as the REST API. 
+ 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. 
+
+=== Listeners, Modules, and registration ===
+
+In general, modules are implementations of several interfaces, including, but not limited to:  
+
+ * `IFloodlightModule` - defines interfaces uniform across modules
+ * `IOFSwitchListener` - lets a module be notified of switches joining and leaving
+ * `IOFMessageListener` - lets a module be notified of various types of !OpenFlow messages
+
+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 such as ''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.  
 
 === Startup ===
@@ -112 +131 @@
 
 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]] 
-  * `IFloodlightModule` is the interface that lets you define Floodlight module behavior in a uniform way. 
-  * 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''.
+  * 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).
   * The structure ''moduleSet'' will ultimately contain the minimum number of modules that need to be loaded at startup. 
   
@@ -120 +138 @@
 `IFloodlightModuleContext` provides a clean mechanism for retrieving references to the loaded modules/services, and their configuration parameters. `FloodlightModuleContext` implements this interface. [[BR]]
   * `IRestApiService` provides REST API functions.
-  * `IFloodlightProviderService` provides the core controller functions and then some. 
+  * `IFloodlightProviderService` as mentioned prior, provides the core controller functions and then some. 
 
 3. Run the REST API and core controller. 
 
-At this point, Floodlight is up and running. The TCP server functions are implemented with [http://netty.io/ Netty]. The controller's ''run'' routine does two things:
- 1. create a server-side channel on port 6633 (or where specified)  
+At this point, Floodlight is up and running. The TCP server functions are implemented with [http://netty.io/ Netty]. The controller's ''run()'' routine does two things:
+ 1. create a server-side channel on port 6633 
  1. handle updates. 
-Updates include switches joining and departing, controller role change, and controller IP change. 
-
-=== IFloodlightProviderService ===
-This interface lies at the core of Floodlight's functions (literally in net.floodlightcontroller.core). The class `Controller` implements this interface and defines Floodlight's corre controller functionalities. 
+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 ====