To begin with, let's look at two basic components of Ryu code that we have seen in the switch application:

• ryu.base.app_manager: The component that centrally manages Ryu applications. ryu.base.app_manager.RyuApp is the base class that all Ryu applications inherit. It provides contexts to Ryu applications and routes messages among Ryu applications (contexts are ordinary Python objects shared among Ryu applications). It also contains methods such as send_event or send_event_to_observers to raise OpenFlow events.
• ryu.controller: The ryu.controller.controller handles connections from switches and routes events to appropriate entities:
  • ryu.controller.ofp_event: This is the OpenFlow event definition.
  • ryu.controller.ofp_handler: This is the handler of an OpenFlow event. A Ryu application registers itself to listen for specific events using ryu.controller.handler.set_ev_cls decorator. We have seen the decorator set_ev_cls as well as CONFIG_DISPATCHER and MAIN_DISPATCHER from the handler.

Each Ryu application has an event-received queue that is first-in, first-out with the event order preserved. Ryu applications are single-threaded, and the thread keeps draining the received queue by dequeueing and calling the appropriate event handler for different event types. We have seen two examples of it so far in the simple_switch_13.py application. The first was the handling of ryu.controller.ofp_event.EventOFSwitchFeatures for switch feature negotiation from the switch:

@set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
def switch_features_handler(self, ev):
    datapath = ev.msg.datapath
    ofproto = datapath.ofproto
    parser = datapath.ofproto_parser
...

The second example was ryu.controller.ofp_event.EventOFPacketIn. A PacketIn event is what the switch sends to the controller when there is a flow miss:

@set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
def _packet_in_handler(self, ev):
    if ev.msg.msg_len < ev.msg.total_len:
        self.logger.debug("packet truncated: only %s of %s bytes",
                          ev.msg.msg_len, ev.msg.total_len)
...

The two examples show the conventions used in Ryu for OpenFlow events; they are named ryu.controller.ofp_event.EventOF<name>, where <name> is the OpenFlow message. The Ryu controller automatically decodes the message and sends it to the registered function. There are two common attributes for the ryu.controller.opf_event.EVentOFMsgBase class:

The function of the event will take the event object as input and examine the msg and msg.datapath attributes. For example, in chapter11_1.py, we stripped out all the code for ryu.controller.ofp_event.EventOFPSwitchFeatures and decoded it from the event object:

from ryu.base import app_manager
from ryu.controller import ofp_event
from ryu.controller.handler import CONFIG_DISPATCHER, MAIN_DISPATCHER
from ryu.controller.handler import set_ev_cls
from ryu.ofproto import ofproto_v1_3

class SimpleSwitch13(app_manager.RyuApp):
    OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]

    def __init__(self, *args, **kwargs):
        super(SimpleSwitch13, self).__init__(*args, **kwargs)
        self.mac_to_port = {}

    # Catching Switch Features Events
    @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
    def switch_features_handler(self, ev):

        print("EventOFPSwitchFeatures: datapath_id {}, n_buffers {} capabilities {}".format(ev.msg.datapath_id,                                                                                        
                        ev.msg.n_buffers,
                        ev.msg.capabilities))

This will print out the following message for the switch feature received:

EventOFPSwitchFeatures: datapath_id 1, n_buffers 256 capabilities 79

As you become more familiar with the Ryu framework, the API document will become a much-read reference: http://ryu-ippouzumi.readthedocs.io/en/latest/ofproto_ref.html#ofproto-ref.

Because switch registration is such as common operation, the Ryu controller typically takes care of the handshake of feature request and reply. It is probably more relevant for us to take a look at the parsing packet in a PacketIn event. This is what we will be doing in the next section.