Dear Murphy:
Thanks. Now I add some extra events and named it as Fail_server_invoke.py like below: from pox.core import core import pox.openflow.libopenflow_01 as of from pox.lib.revent.revent import EventMixin log = core.getLogger() class define_event(EventMixin): _eventMixin_events = set([raise_fail]) class Fail_server_invoke(object): def __init__(self, intervals): self.connections = set()# Attribute self.interval = intervals define_event.addListeners(self) #Add Listener log.debug(" --------------------------------- ") log.debug(" Fail_server_invoke_class wait for raise_fail event ") log.debug(" --------------------------------- ") def _handle_raise_fail (self, event): log.debug("Server failed") But I got some problems when I use another component to add following lines in launch function. core.registerNew( Fail_server_invoke, interval) define_event.raiseEvent(raise_fail("Generic")) And I also import the module Fail_server_invoke like below: from Fail_server_invoke import * The error message is 'NameError: name 'raise_fail' is not defined', but I already define 'raise_fail' in Fail_server_invoke.py Thanks for helping. Best Regards, Sophia 2013/3/30 Murphy McCauley <murphy.mccau...@gmail.com> > On Mar 29, 2013, at 11:40 PM, chenli wrote: > > > 1. The meaning for registering > > Is core.registerNew(Mycomponent) the function to register to core > object, and we can use the methods in core which defined in > /pox/pox/core.py ? > > > > If I register the Mycomponent to core, the other components can > communicate with Mycomponent by core object? > > I think the answer here is yes. One of the purposes of the core object is > to provide a rendezvous point for component instances. This allows a > number of things, not all of which are really used extensively at this > point: > 1) It means you often just need to import core instead of a whole bunch of > modules. > 2) Multiple components that all implement the same interface can register > under the same name and other components can find the active one. > 3) It's not always clear where long-lived objects should be. One option > is as a global variable of some module. core is a (possibly) more > structured alternative which (among other things) hopefully encourages > components to be capable of being instantiated more than once. (In > practice, this is rarely true so far.) > > > 2. The code section for raising ConnectionUp event > > And the second problem , I want to know where is the raiseEvent which > raise ConnectionUp event happened. In other words, maybe it looks like > core.openflow.raiseEvent(ConnectionUp). > > > I'm not sure why it's helpful to know exactly where this event is raised, > but it's in openflow.of_01 along with the rest of the stuff specific to > communicating with OpenFlow 1.0 switches (not counting the stuff related to > the OpenFlow protocol itself which is in libopenflow_01). > > It's slightly more complicated than just raising it on core.openflow. > Connection objects are "owned" by an OpenFlowNexus. core.openflow is the > default nexus, but there can be others. So the actual ConnectionUp event > is raised on whichever nexus the Connection belongs to. > > -- Murphy