Ryu applications are basically Python modules that define a subclass of ryu.base.app_manager.RyuApp. Two or more classes could be defined in a single module but priority is given to the first module sorted by name order and this is processed by the app manager. One instance of any Ryu application can run at a time in an environment. To run an application in the environment, you need to run the following script:

% ryu-manager MyFirstApplication.py 
where MyFirstApplication refers to the application name which works as a simple Layer Two switch. 

The application can be found as follows:

from ryu.base import app_manager 
from ryu.controller import ofp_event 
from ryu.controller.handler import MAIN_DISPATCHER 
from ryu.controller.handler import set_ev_cls 
class MyFirstApplication(app_manager.RyuApp): 
         def __init__(self, *args, **kwargs): 
   super(MyFirstApplication, self).__init__(*args, **kwargs) 
   @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER) 
 
        def packet_in_handler(self, ev): 
   msg = ev.msg 
   dp = msg.datapath 
   ofp = dp.ofproto 
   ofp_parser = dp.ofproto_parser 
 
   actions = [ofp_parser.OFPActionOutput(ofp.OFPP_FLOOD)] 
   out = ofp_parser.OFPPacketOut( 
            datapath=dp, buffer_id=msg.buffer_id, in_port=msg.in_port, actions=actions) 
   dp.send_msg(out) 

A Ryu application raises an event or receives an event. To raise events, the Ryu application calls the appropriate ryu.base.app_manager.RyuApp methods, such as the send_event or send_event_to_observers APIs.

A Ryu application can register itself to listen for specific events using the ryu.controller.handler.set_ev_cls decorator. This decorator tells Ryu when the decorated function should be called.

The first argument for the set_ev_cls decorator indicates the event of interest, which triggers the following function call, allowing the function to be called every time Ryu receives a packet_in message.

The second argument indicates the state of the switch. In a scenario where you need the application to ignore packet_in messages before the negotiation between the Ryu controller and the switch finishes, it can use MAIN_DISPATCHER as the second argument, which indicates that the following function is called only after the negotiation has been completed.

In our example, our application is interested in packet_in events, and every time the Ryu controller gets a packet_in message, a handler function should be called. In addition, our application is able to send a received packet to all ports.

Take a look at the first half of the packet_in_handler function:

ev.msg is an object that represents a packet_in data structure. 
msg.dp is an object that represents a datapath (switch). 
dp.ofproto and dp.ofproto_parser are objects that represent the OpenFlow protocol that Ryu and the switch negotiated. 

And here is the second half:

• The OFPActionOutput class is used with a packet_out message to specify a switch port that you want to send the packet out of. In our case, the application needs to send out from all the ports of the switch, so OFPP_FLOOD constant is used.
• The OFPPacketOut class is used to build a packet_out message.
• If you call datapath class's send_msg method with a with an OpenFlow message class object, the controller builds the message and sends the on-wire data format to the switch.