Changes between Version 1 and Version 2 of Internal/OpenFlow/VendorTutorial

Timestamp:

Dec 21, 2012, 10:36:11 PM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/VendorTutorial

@@ -24 +24 @@
 This base class can then be subclassed to implement the various types of this message.  
 
-The Vendor ID and VendorData must be registered before it can properly be parsed by your controller. Floodlight's core controller class, `Controller`, registers each vendor message and its subtypes during startup by calling initVendorMessages():
+The Vendor ID and !VendorData must be registered before it can properly be parsed by your controller. Floodlight's core controller class, `Controller`, registers each vendor message and its subtypes during startup by calling initVendorMessages():
 {{{
     private void initVendorMessages() {
-        // Configure openflowj to be able to parse the role request/reply
-        // vendor messages.
-        OFBasicVendorId niciraVendorId = new OFBasicVendorId(             (1)
+        // Configure openflowj to be able to parse the role request/reply vendor messages.
+        // first register the vendor ID
+        OFBasicVendorId niciraVendorId = new OFBasicVendorId(             
                 OFNiciraVendorData.NX_VENDOR_ID, 4);
         OFVendorId.registerVendorId(niciraVendorId);
-        OFBasicVendorDataType roleRequestVendorData =                     (
+        // then each data type 
+        OFBasicVendorDataType roleRequestVendorData =                     
                 new OFBasicVendorDataType(
                         OFRoleRequestVendorData.NXT_ROLE_REQUEST,
@@ -44 +45 @@
     }
 }}}
+Where NXT_ROLE_REQUEST and NXT_ROLE_REPLY are the request and reply data types. 
 
+As seen above in the instantiation of the OFBasicVendorDataType,
+the class implementing the vendor data should be instantiable, so that
+it can be registered properly by the controller. It seems customary to
+provide a method, getInstantiable(), for this purpose. This belongs in
+the subclass that defines the actual vendor data payload. The code that
+does this may look like this:
 {{{
-   // register vendor ID
-    OFBasicVendorId ofvid = new OFBasicVendorId(CPL_VENDOR_ID, 4);
-    OFVendorId.registerVendorId(ofvid);
+    protected static Instantiable<OFVendorData> instantiable =
+            new Instantiable<OFVendorData>() {
+                public OFVendorData instantiate() {
+                    return new OFExportsReply();
+                }
+            };
 
-    // and then the message types
-    OFBasicVendorDataType ofvdt = new OFBasicVendorDataType(20,
-            OFExportsReply.getInstantiable());
-    ofvid.registerVendorDataType(ofvdt);
+    /**
+     * @return a subclass of Instantiable<OFVendorData> that instantiates
+     *         an instance of OFRoleRequestVendorData.
+     */
+    public static Instantiable<OFVendorData> getInstantiable() {
+        return instantiable;
+    }
 }}}
+The above sample was modified slightly to fit my vendor message, but
+was almost taken, word-for-word, from the Nicira vendor messages.
 
 A non-registered Vendor message data payload is interpreted simply as a byte array (OFByteArrayVendorData to be precise), and is not easily processed e.g. the methods in your VendorData classes would not be applicable as you would not be able to cast the byte array to your message (sub)class(es).