Changes between Version 6 and Version 7 of Internal/OpenFlow/Controllers/Nox

Timestamp:

Nov 9, 2010, 7:53:00 PM (15 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/Controllers/Nox

@@ -84 +84 @@
 }}}
 
-== 3. Customizing your component ==
+= 3. Customizing your component =
 All applications under nox are found in either netapps., coreapps, or webapps. Each app is contained in a directory that includes code for the applications' modules (e.g. routing modules implementing specific algorithms), and a list, named meta.json, used by nox to find and load modules at startup. 
 
 By itself, your new component only knows how to initiate a channel with an !OpenFlow switch, and to start up the "liveness check" echo requests. This section is a compilation of information on the nox libraries that can be used to define your own controller. 
 
-== 3.1 Adding flags. ==
-The `configure` function allows you to define options for your application. When starting nox_core, flags can be specified by the application name, followed by an '=', then your flag(s):
+== 3.1 The configure function. ==
+The `configure` function allows you to register the events that the module will respond to via the `Disposition` type function (more detail later on regarding this), and to define options for your application. 
+
+=== 3.1.1. starting modules with flags ===
+When starting nox_core, flags can be specified by the application name, followed by an '=', then your flag(s):
 {{{
 ./nox_core -v -i ptcp:6633 switch="noflow"
@@ -96 +99 @@
 I'm guessing if it can take multiple options, you can string multiple flags by delimiting each option with a comma or another '='.
 
+=== 3.1.2. registering events. ===
+This is done with the `register_handler` which takes your event's name and allows you to specify a NOX event to bind to it:
+
+{{{
+ register_handler<Flow_in_event>
+        (boost::bind(&SPRouting::handle_flow_in, this, _1));
+}}}
+Here, a Flow_in_event (defined in NOX libraries) is taken as an argument to the module specific Disposition type function `handle_flow_in`.
+
+This snippet is taken from the built-in routing module (netapps/routing/sprouting.cc, .hh) which makes an OF switch behave like a router. The sprouting module is fairly complex and can be used to see how a module is built; we'll be using pieces of this module (along with others where specified) throughout this page.  
+
+=== 3.1.3. defining flags/options. ===
+It seems customary to define and check for flags within configure function, but this doesn't have to be the case. For example, in sprouting, there is a separate function called `validate_args`.
  
+A more "traditional" way of doing this is through the Configuration object (found in  nox/src/nox/component.hh):
+{{{
+class Configuration {
+public:
+    virtual ~Configuration();
+    
+    /* Retrieve a value of an XML configuration key. */
+    virtual const std::string get(const std::string& key) const = 0;
+
+    /* Return true if the XML key exists. */
+    virtual const bool has(const std::string& key) const = 0;
+
+    /* Return all XML keys. */
+    virtual const std::list<std::string> keys() const = 0;
+    
+    /* Return all command line arguments of the component. */
+    virtual const Component_argument_list get_arguments() const = 0;
+
+    /* Return list of arguments. */
+    virtual const hash_map<std::string, std::string> 
+    get_arguments_list(char d1 = ',', char d2 = '=') const = 0;
+};
+}}}
+
+This class allows you to input flags as described earlier in 3.1.1. Actually using the class involves something like this (from switch.cc). 
+{{{
+Switch::configure(const Configuration* conf) {
+...
+   BOOST_FOREACH (const std::string& arg, conf->get_arguments()) {
+        if (arg == "noflow") {
+            setup_flows = false;
+        } else {
+            VLOG_WARN(log, "argument \"%s\" not supported", arg.c_str());
+        }
+    }
+...
+}}}
+ 
+== 3.2. Event triggers ==
+=== 3.2.1 The Disposition type ===
+