Changes between Version 5 and Version 6 of Internal/OpenFlow/Controllers/FloodLight


Ignore:
Timestamp:
May 12, 2012, 10:47:01 PM (12 years ago)
Author:
akoshibe
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Internal/OpenFlow/Controllers/FloodLight

    v5 v6  
    4040 * Click Run->Run Configurations
    4141 * Right Click Java Application->New
    42  * For Name use FloodlightLaunch
     42 * For Name use '!FloodlightLaunch'
    4343 * For Project use Floodlight
    4444 * For Main use net.floodlightcontroller.core.Main
     
    5050== Adding functionality. == #modding
    5151A base tutorial can be found [http://floodlight.openflowhub.org/developing-floodlight/ here]. The steps assume that you are using Eclipse. The rough steps are the following:
    52  1. Create a new class under src/main/java, basing it off of a template, if it exists
    53  2. Register the module so that it is loaded at startup. This involves adding the fully qualified module name to two files:
     52 1. Create a new class under src/main/java, with the proper interfaces.
     53 1. Export services if it interacts with other services e.g. the REST API.
     54 1. Register the module so that it is loaded at startup. This involves adding the fully qualified module name to two files:
    5455  * ''' net.floodlight.core.module.IFloodlightModule ''' - list of modules recognized by the loader
    5556  * ''' floodlightdefault.properties ''' - list of modules to be loaded at startup.
     57
     58=== Some module components ===
     59 * IFloodlightProviderService : Needed for listening to !OpenFlow messages by registering with the !FloodlightProvider.
     60 * getModuleDependencies() : in a module, the function to indicate dependencies to the module loader e.g the IFloodlightProviderService above. This is probably the function that is called by the loader when it searches for loadable modules and tries to discern its dependencies.
     61 * getModuleServices() : in a module, the function to indicate services exported by the module.
     62 * getServiceImpls() :
     63 * init() : in a module, the function where contexts are defined for services that the module is dependent on. It seems to be similar to a constructor.
     64 * isCallbackOrderingPrereq(), isCallbackOrderingPostreq() : where the module should be in the message processing chain.
     65 * startUp() : in a module, defines external initializations associated with other modules to which it is dependent on.
     66 * receive() : defines what a module does when it receives an event e.g. the one specified in startUp().   
     67
     68=== Exporting services ===
     69 1. create a interface for the service
     70 1. Add interface to the module
     71 1. add classes used by the service e.g. the REST API
    5672
    5773== Architecture == #arch
     
    6278The 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.
    6379
    64 === Some module components ===
    65  * IFloodlightProviderService : Needed for listening to !OpenFlow messages by registering with the !FloodlightProvider.
    66  * getModuleDependencies() : in a module, the function to indicate dependencies to the module loader e.g the IFloodlightProviderService above.
    67  * init() : in a module, the function where contexts are defined for services that the module is dependent on. It seems to be similar to a constructor.
    68  * isCallbackOrderingPrereq(), isCallbackOrderingPostreq() : where the module should be in the message processing chain.
    69  * startUp() : in a module, defines external initializations associated with other modules to which it is dependent on.
    70  * receive() : defines what a module does when it receives an event e.g. the one specified in startUp().   
    7180
    7281= The Floodlight VM = #vm