Une note que j'ai eu du mal à le trouver dans la bibliothèque openflow python ryu car il semble être répertorié dans le tutoriel.
Tout d'abord, dans ryu, écrivez-le comme une application" pilotée par les événements ". Les événements sont des classes dérivées de ryu.event.EventBase.
Lors de l'écriture d'une application openflow, il est courant de dire «d'abord». Avec ryu, je me demande quel événement utiliser en ce moment, mais cela semble être une bonne chose.
app.py
from ryu.base import app_manager
from ryu.controller import ofp_event
from ryu.controller.handler import set_ev_cls, MAIN_DISPATCHER
class App1(app_manager.RyuApp):
@set_ev_cls(ofp_event.EventOFPStateChange, MAIN_DISPATCHER)
def on_switch_ready(self, ev):
assert isinstance(ev, ofp_event.EventOFPStateChange)
print("switch ready")
Exemple d'exécution. Par exemple, sur Ubuntu, vous pouvez l'exécuter en incluant le package ryu-bin.
ryu-manager --config-file=/dev/null app.py
Event
Puisque ryu est axé sur les événements, l'histoire ne commence pas sans connaître l'événement. Sous ryu.controller, qui est utilisé en standard, il y a les événements suivants. Tout d'abord, je vais les énumérer brièvement. J'écrirai un commentaire plus tard.
from représente le côté éditeur de l'événement et to représente le côté abonné.
ryu.controller.ofp_event
Les événements avec une correspondance 1: 1 avec des messages de protocole à flux relativement ouvert sont traités.
système de notification d'état du chemin de données
Ce qui suit est généré dynamiquement en tant que sous-classe de ʻEventOFPMsgBase`. Tous les événements sont générés à partir de la boucle recv.
Système de notification de l'état du port. Publié après EventOFPPortStatus.
ryu.controller.dpset
protocole openflow Un événement qui vous permet de gérer l'activation / la désactivation du chemin de données et l'état d'un port à une couche plus élevée que directement. Il peut être utilisé comme service DPSet.
Pris ensemble, lors de la connexion à un commutateur openflow 1.3, les événements suivants se dérouleront automatiquement:
Ainsi, les soi-disant points prêts pour le commutateur sont ʻEventOFPStateChange, MAIN_DISPATCHER ou ʻEventDP.
Service
Comme le DPSet ci-dessus, les sources d'événements peuvent maintenant être ajoutées en tant que services. Les services sont identifiés par des chaînes à l'intérieur de ryu. Les services suivants existent dans ryu. Ceux-ci sont généralement activés automatiquement lorsque vous enregistrez un gestionnaire d'événements et commencez à l'utiliser (set_ev_cls).
Par exemple, pour utiliser ryu.controller.dpset:
app2.py
from ryu.base import app_manager
from ryu.controller import dpset, ofp_event
from ryu.controller.handler import set_ev_cls
class App2(app_manager.RyuApp):
@set_ev_cls(dpset.EventDP)
def on_dp_change(self, ev):
print("datapath event", ev.enter)
L'exemple suivant est également une fourmi en tant que point de commutation prêt à l'aide de Service.
app3.py
import ryu.topology.event
from ryu.base import app_manager
from ryu.controller.handler import set_ev_cls
class App3(app_manager.RyuApp):
@set_ev_cls(ryu.topology.event.EventSwitchEnter)
def on_enter(self, ev):
print("switch ready")
Dependent singleton
En tant que formulaire non desservi, vous pouvez également vous inscrire et utiliser une classe qui dépend explicitement de RyuApp._CONTEXTS. Généré en tant que singleton au démarrage et passé via kwargs dans RyuApp .__ init__.
app4.py
from ryu.base import app_manager
class A(object):
def __init__(self):
print("init A")
class App4(app_manager.RyuApp):
_CONTEXTS = dict(a=A)
def __init__(self, *args, **kwargs):
super(App4, self).__init__(*args, **kwargs)
print(kwargs)
Cet exemple ne définit pas de gestionnaire pour le message openflow, quittez donc une fois l'initialisation terminée. Le ryu lui-même est un hub d'événements, et le protocole openflow semble avoir été créé avec l'idée qu'il s'agit d'une des applications pilotées par les événements de la catégorie ʻofp_event`.