Changes between Version 8 and Version 9 of Internal/OpenFlow/VendorTutorial
- Timestamp:
- Jan 2, 2013, 10:43:36 PM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Internal/OpenFlow/VendorTutorial
v8 v9 33 33 34 34 === 2.1 The Vendor Message Header === 35 What we 're referring to as the vendor message headeris typically a set of variables defined in the class that implements `OFVendorData`. The class in which these variables are declared typically becomes the base class for further message types.35 What we refer to as the "vendor message header" is typically a set of variables defined in the class that implements `OFVendorData`. The class in which these variables are declared typically becomes the base class for further message types. 36 36 37 37 For example, the vendor ID and data type are part of `OFNiciraVendorData`, the base class for all Nicira vendor messages: … … 47 47 ... 48 48 }}} 49 This class is extended to implement the Request and Reply message types (`OFRoleRequestVendorData` and `OFRoleReplyVendorData`, respectively). Note how at (1) the value of dataType is not set here - this value is set through the base class's constructor, which takes a integer value for the !dataType:49 `OFNiciraVendorData` is extended to implement the Request and Reply message types (`OFRoleRequestVendorData` and `OFRoleReplyVendorData`, respectively). Note how at (1) the value of dataType is not set within this class - this value is set through the base class's constructor, which takes an integer value for the dataType: 50 50 {{{ 51 51 /** … … 57 57 } 58 58 }}} 59 The values passed to this constructor are declared in each subclass that represents a message type, as we can see herein `OFRoleReplyVendorData`:59 The values passed to this constructor are found in each subclass that represents a message type. We can see this in `OFRoleReplyVendorData`: 60 60 {{{ 61 61 /** … … 73 73 If we trace back, we learn that super() above refers to the constructor of `OFRoleVendorData`, a subclass of `OFNiciraVendorData`. `OFRoleVendorData` takes the value passed to it by `OFRoleReplyVendorData` and passes it to the constructor of its parent class. 74 74 75 This organization isn't a requirement, but makes code reuse easier. The "nesting" of message classes can be thought of as implementing the message structure in layers - Each subclass implements message components that are encapsulated by components implemented in its parent class.75 This organization isn't a requirement, but makes code reuse easier. The "nesting" of message classes can be thought of as implementing the message structure in layers - Each subclass implements either message components that are encapsulated by components in its parent class, or methods that assign values to variables declared in its super-classes, like in the example above. 76 76 77 77 The Vendor ID and data type are the only requirements in terms of vendor header content. Given that the methods required by `OFVendorData` are provided, along with those required for message registration, the message implementation may be structured as needed. The usual additions are various message fields and their getters and setters. … … 154 154 } 155 155 }}} 156 super () points to`OFNiciraVendorData`, which takes care of reading and writing the integral dataType field:156 super in this case is `OFNiciraVendorData`, which takes care of reading and writing the integral dataType field: 157 157 {{{ 158 158 @Override … … 181 181 } 182 182 }}} 183 184 == 3. The full Vendor Message == 185 This section describes how to construct the full vendor type message once we have a structured vendor data object, or alternatively, parse a vendor type message containing a known type of vendor data. 186 187 === 3.1 Message construction === 188 The vendor data is just the payload of an !OpenFlow vendor type message. The !OpenFlow header must be added to the vendor data before it can be sent out on the channel. 189 190 === 3.2 Reading message contents ===
