Thanks for your reply, please find code and output below.
I have done some minimal debugging, and know that register_observer is over
writing the states for the app class each time it is called. It expects one
method with multiple states instead of multiple methods each registered for
one state.
Granted, I don’t fully understand this process yet as I’m not sure why the
method along with the class is not being stored - though I feel this may be
part of the problem. I haven’t looked at where the events are being picked
up by the observers yet – which must be responsible for calling all of the
registered methods for this event, regardless of their registered
dispatcher.
##### CODE #####
import logging
import struct
from ryu.base import app_manager
from ryu.controller import mac_to_port
from ryu.controller import ofp_event
from ryu.controller.handler import set_ev_cls
from ryu.ofproto import ofproto_v1_3
from ryu.ofproto import ofproto_v1_3_parser
from ryu.lib.mac import haddr_to_str
from ryu.controller.controller import Datapath
from ryu.controller.handler import HANDSHAKE_DISPATCHER
from ryu.controller.handler import CONFIG_DISPATCHER
from ryu.controller.handler import DEAD_DISPATCHER
from ryu.controller.handler import MAIN_DISPATCHER
class PacketTesting(app_manager.RyuApp):
OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]
def __init__(self, *args, **kwargs):
super(PacketTesting, self).__init__(*args, **kwargs)
@set_ev_cls(ofp_event.EventOFPEchoRequest, MAIN_DISPATCHER)
def _echo_rep_main(self, ev):
print "DEBUG: In Handler for Echo Request (Main)"
@set_ev_cls(ofp_event.EventOFPEchoRequest, CONFIG_DISPATCHER)
def _echo_rep_conf(self, ev):
print "DEBUG: In Handler for Echo Request (Config)"
@set_ev_cls(ofp_event.EventOFPEchoRequest, HANDSHAKE_DISPATCHER)
def _echo_rep_hand(self, ev):
print "DEBUG: In Handler for Echo Request (Handshake)"
@set_ev_cls(ofp_event.EventOFPEchoRequest, DEAD_DISPATCHER)
def _echo_rep_dead(self, ev):
print "DEBUG: In Handler for Echo Request (Dead)"
##### OUTPUT #####
loading app ../ryu_echo_req_ex.py
loading app ryu.controller.ofp_handler
instantiating app ../ryu_echo_req_ex.py
instantiating app ryu.controller.ofp_handler
BRICK PacketTesting
CONSUMES EventOFPEchoRequest
BRICK ofp_event
PROVIDES EventOFPEchoRequest TO {'PacketTesting': ['main']}
CONSUMES EventOFPErrorMsg
CONSUMES EventOFPEchoRequest
CONSUMES EventOFPSwitchFeatures
CONSUMES EventOFPHello
connected socket:<eventlet.greenio.GreenSocket object at 0xa0fb84c>
address:('127.0.0.1', 60098)
hello ev <ryu.controller.ofp_event.EventOFPHello object at 0xa0fbb6c>
move onto config mode
switch features ev version: 0x4 msg_type 0x6 xid 0xf8480126
OFPSwitchFeatures(auxiliary_id=0,capabilities=71,datapath_id=153,n_buffers=256,n_tables=254,reserved=0)
move onto main mode
EVENT ofp_event->PacketTesting EventOFPEchoRequest
DEBUG: In Handler for Echo Request (Config)
DEBUG: In Handler for Echo Request (Dead)
DEBUG: In Handler for Echo Request (Handshake)
DEBUG: In Handler for Echo Request (Main)
EVENT ofp_event->PacketTesting EventOFPEchoRequest
DEBUG: In Handler for Echo Request (Config)
DEBUG: In Handler for Echo Request (Dead)
DEBUG: In Handler for Echo Request (Handshake)
DEBUG: In Handler for Echo Request (Main)
On 3 Jul 2013 07:41, "Isaku Yamahata" <[email protected]> wrote:
> Your expectation sounds correct. Posting your code would help.
>
> thanks,
>
> On Tue, Jul 02, 2013 at 01:54:20PM +0100, Alan Barr wrote:
> > Hello all,
> >
> >
> >
> > I was wondering if someone could clarify if what I am seeing is expected
> > behaviour.
> >
> > I am new to Ryu and currently trying to familiarise myself with it.
> >
> > In one of my test applications I have registered four different methods
> for
> > EventOFPEchoRequest, one method for each of HANDSHAKE, CONFIG, MAIN and
> DEAD
> > dispatchers.
> >
> > When this event is triggered, all of these methods are called, not just
> the one
> > registered for the appropriate state.
> >
> >
> >
> > Is this the correct behaviour? I don't have a valid use case of this,
> I'm just
> > trying to better understand Ryu and this was my first test setup. I
> wasn?t
> > expecting this behaviour.
> >
> >
> >
> > I was basing this off:
> >
> >
> >
> > ?A decorator for Ryu application to declare an event handler. Decorated
> method
> > will become an event handler. ev_cls is an event class whose instances
> this
> > RyuApp wants to receive. dispatchers argument specifies one of the
> following
> > negotiation phases (or a list of them) for which events should be
> generated for
> > this handler. Note that, in case an event changes the phase, the phase
> before
> > the change is used to check the interest.?
> https://github.com/osrg/ryu/wiki/API
> >
> >
> >
> > I'm on commit a66bcf031d782c25b987431feb76251970158573.
> >
> >
> >
> > Kind Regards,
> >
> > Alan Barr
> >
> >
> >
>
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Windows:
> >
> > Build for Windows Store.
> >
> > http://p.sf.net/sfu/windows-dev2dev
> > _______________________________________________
> > Ryu-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/ryu-devel
>
>
> --
> yamahata
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Ryu-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Ryu-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ryu-devel
