From OpenFlow Wiki

You should extend ConnectionHandler to something like EXConnectionHandler. This will enable you to process messages specific to your extension. You will also be able to handle base messages and connection events in new ways if needed.

Extending ConnectionHandler

1. Implement the constructor.
2. Override connectionStateChange() if you need to send a message to the backend when the connection first starts, or if you need to do special processing when the connection is disconnected.
3. Override process(OFGMessage msg) in order to handle your custom messages or to handle existing messages in new ways.

Adding a new message

1. The enumeration OFGMessageType lists a name and unique identifier for every message. To create a new message type, simply add a new item to the list with an unused message ID. The convention is to prefix your message types with a short abbreviation for your program to distinguish it from the base messages. It is also recommended that you use an ID number starting with 0xF0 as these are guaranteed to be reserved for extensions. Example:

 /** Info about power usage. */
 EX_POWER_USAGE((byte)0xF0)

2. Create a new class to represent your new message. The class should be put in a subpackage of org.openflow.gui.net.protocol (the subpackage name should be the abbreviation for our program). The name of the class should be the same as the enumeration constant you just added (with appropriate capitalization). In our example, we would create a class EXPowerUsage in the org.openflow.gui.net.protocol.ex package.

3. Your new class should extend OFGMessage (or maybe one of its subclasses like NodesList if your message is a list of common things like nodes [e.g., switches, hosts, ...]). It will be very similar in construction to existing protocol messages, so you should read through a few of them. By convention, data fields of a message are public and final. In particular, your message class should include the following methods:

• A constructor used for reading in the message: EXPowerUsage(int len, int xid, DataInput in)
• Override length() to return the length of your message in bytes. The body should be something like: return super.length() + your_messages_size
• Override write(DataOutput out) to write the message. The body should start with super.write(out) (to write the parent's header ad data) and be followed by calls on the out object which serialize your message.
• Override toString() to describe the contents of your message - you can start with super.toString().

4. OFGMessageType is responsible for calling the constructor of the appropriate message type when a message of that type is being received. The private decode() method should be modified to have a case which calls the constructor of your new message type. If the message should only be sent from the GUI to the backend, then you should add it to the bottom of the switch statement which throws an exception due to the receipt of an unexpected message type. Example:

 case EX_POWER_USAGE:
 return new EXPowerUsage(len, xid, in);

5. You should have extended ConnectionHandler to something like EXConnectionHandler. In the process() method, add a case to the switch statement for handling your new message:

 case EX_POWER_USAGE:
   processPowerUsage((EXPowerUsage)msg);
   break;