Ok Iwase I'm willing to give it a try at ZMQ. I will read the documentation you gave me and then come back at a later time to tell you how it went.
Once again, thank you for your support. Carlos On 21 December 2017 at 01:35, Iwase Yusuke <iwase.yusu...@gmail.com> wrote: > Hi Carlos, > > Hmmm... It seems that your problem is whether Pyro4 can work on (or > cooperate > with) GreanThreads. > I don't know much about Pyro4, if Pyro4 (client side at least) can work on > GreanThreads, you can call Pyro4's APIs on your Ryu application, I guess. > > Ryu is designed for using non-blocking with eventlet and it is difficult to > draw their thread back to Native Threads, so if you need to communicate to > native threads, you need to some mechanism to realize it. > > Anyway, the mixing of Native Threads and GreanThreads should be avoided, you > need to separate process (Ryu and Pyro4 client) first. > > working on working on > non-blocking mode blocking mode > <=============> <===========================> > Ryu RyuApp Pyro4 Client Pyro4 Server > | event | | | > |------>| some mechanism(*) | | > | |------------------>| Request | > | | |-------->| > | | | Reply | > | | some mechanism(*) |<--------| > | |<------------------| | > > For (*) in the above, if you prefer to use Queue, how about using Push/Pull > pattern of ZeroMQ? > The following describes the way to create a Queue like object with ZeroMQ. > http://learning-0mq-with-pyzmq.readthedocs.io/en/latest/pyzmq/patterns/pushpull.html > Please note that, on Ryu, you need to use Eventlet's ZeroMQ instead of > "pyzmq", > but the usage seems to be almost the same. > http://eventlet.net/doc/modules/zmq.html > > Thanks, > Iwase > > > > On 2017年12月21日 09:48, Carlos Ferreira wrote: >> >> Thank you Iwase. >> >> I was actually thinking in using queues to synchronise information >> between Ryu's threads and native threads, since I'm also using Pyro4 >> to communicate with another service. >> But my doubt here is, how can I suspend a Ryu thread and make it wait >> for a message to arrive at a queue? >> I have never used ZeroMQ and I wanted to use a simple mechanism, like >> the native Python queue.Queue, for example. >> >> Carlos >> >> >> On 20 December 2017 at 23:45, Iwase Yusuke <iwase.yusu...@gmail.com> >> wrote: >>> >>> Hi Carlos, >>> >>> Please let me confirm your issue first. >>> Your question is how to suspend the current thread waiting for some works >>> finished (REST request? or other thread?), right? >>> To suspend your threads using ryu.lib.hub.spawn, you can use >>> "eventlet.event" >>> which is similar to a Queue or threading.Lock. >>> http://eventlet.net/doc/modules/event.html >>> >>> For example: >>> >>> Ryu xxx_handler thread worker >>> | Event | | | >>> |------>| | | >>> | | hub.spawn | | >>> | |---------->| | >>> | | | request some | >>> | | |------------->| >>> | | | response | >>> | | FlowMod |<-------------| >>> | | request | | >>> |<------------------| | >>> | | | | >>> >>> >>> On this situation, your problem is mixing the Native Threads and the >>> GreenThreads? >>> As far as I know, the Native Threads behave (normally) as IO blocking >>> threads >>> and Ryu's threads (using ryu.lib.hub.spawn) behave as non-blocking >>> threads. >>> Generally, it is not recommended to mix blocking and non-blocking in the >>> same >>> process, if these need to cooperate, I guess some APIs like socket (TCP, >>> REST or >>> so), file, messaging queue(http://eventlet.net/doc/zeromq.html) is better >>> way to >>> communicate between blocking and non-blocking. >>> >>> Does someone know more better way? >>> >>> >>> Thanks, >>> Iwase >>> >>> >>> >>> On 2017年12月20日 07:52, Carlos Ferreira wrote: >>>> >>>> >>>> Iwase, can you help me here, please? >>>> >>>> Thank you! >>>> >>>> Carlos Ferreira >>>> >>>> On 18 December 2017 at 11:16, Carlos Ferreira <carlosmf...@gmail.com> >>>> wrote: >>>>> >>>>> >>>>> Hmm, suspending all Ryu activities that is precisely what I was trying >>>>> to >>>>> avoid. >>>>> >>>>> Ok I have another idea. Instead of having the coroutine waiting for >>>>> some work to be processed, what if I have a Python thread creating a >>>>> new coroutine using ryu.lib.hub.spawn, which will then active the >>>>> necessary flows when a decision is ready to be implemented? >>>>> >>>>> I had issues in the past, when mixing Threads and the greenlet >>>>> coroutines, having problems when sharing information between them. >>>>> >>>>> Thank you Iwase, for your help! >>>>> >>>>> >>>>> On 18 December 2017 at 05:39, Iwase Yusuke <iwase.yusu...@gmail.com> >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi Carlos, >>>>>> >>>>>> Well, as far as I know, Ryu does not provides the features for >>>>>> suspending >>>>>> the >>>>>> specific activities (e.g., threads) of Ryu, so I guess you can only >>>>>> suspend >>>>>> all activities at the same time. >>>>>> >>>>>> Just an idea, the following suspends all Ryu activities when calling >>>>>> sleep() >>>>>> and prevents other threads getting executed. >>>>>> The following uses the "non-patched" time module to suspend >>>>>> greanthread. >>>>>> If you need some locks, please use threading.Lock instead of >>>>>> time.sleep(). >>>>>> >>>>>> >>>>>> $ git diff >>>>>> diff --git a/ryu/app/simple_switch_13.py b/ryu/app/simple_switch_13.py >>>>>> index 06a5d0e..316ee37 100644 >>>>>> --- a/ryu/app/simple_switch_13.py >>>>>> +++ b/ryu/app/simple_switch_13.py >>>>>> @@ -22,6 +22,9 @@ from ryu.lib.packet import packet >>>>>> from ryu.lib.packet import ethernet >>>>>> from ryu.lib.packet import ether_types >>>>>> >>>>>> +from eventlet import patcher >>>>>> +orig_time = patcher.original('time') >>>>>> + >>>>>> >>>>>> class SimpleSwitch13(app_manager.RyuApp): >>>>>> OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION] >>>>>> @@ -29,6 +32,7 @@ class SimpleSwitch13(app_manager.RyuApp): >>>>>> def __init__(self, *args, **kwargs): >>>>>> super(SimpleSwitch13, self).__init__(*args, **kwargs) >>>>>> self.mac_to_port = {} >>>>>> + self.is_something_done = False >>>>>> >>>>>> @set_ev_cls(ofp_event.EventOFPSwitchFeatures, >>>>>> CONFIG_DISPATCHER) >>>>>> def switch_features_handler(self, ev): >>>>>> @@ -63,8 +67,19 @@ class SimpleSwitch13(app_manager.RyuApp): >>>>>> match=match, instructions=inst) >>>>>> datapath.send_msg(mod) >>>>>> >>>>>> + def _do_something_with_global_blocking(self): >>>>>> + if self.is_something_done: >>>>>> + return >>>>>> + >>>>>> + self.logger.info('waiting for done of something...') >>>>>> + orig_time.sleep(10) >>>>>> + self.is_something_done = True >>>>>> + self.logger.info('done.') >>>>>> + >>>>>> @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER) >>>>>> def _packet_in_handler(self, ev): >>>>>> + self._do_something_with_global_blocking() >>>>>> + >>>>>> # If you hit this you might want to increase >>>>>> # the "miss_send_length" of your switch >>>>>> if ev.msg.msg_len < ev.msg.total_len: >>>>>> >>>>>> >>>>>> With the above modification, simple_switch_13.py blocks all Ryu >>>>>> activities >>>>>> while >>>>>> 10 seconds, and Packet-In event will not be handled until done. >>>>>> >>>>>> $ ryu-manager ryu/app/simple_switch_13.py >>>>>> loading app ryu/app/simple_switch_13.py >>>>>> loading app ryu.controller.ofp_handler >>>>>> instantiating app ryu/app/simple_switch_13.py of SimpleSwitch13 >>>>>> instantiating app ryu.controller.ofp_handler of OFPHandler >>>>>> waiting for done of something... >>>>>> done. >>>>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>>>> packet in 1 c2:09:7b:d2:6c:a2 ff:ff:ff:ff:ff:ff 1 >>>>>> packet in 1 82:3d:bb:d5:d6:ba c2:09:7b:d2:6c:a2 2 >>>>>> packet in 1 c2:09:7b:d2:6c:a2 82:3d:bb:d5:d6:ba 1 >>>>>> packet in 1 c2:09:7b:d2:6c:a2 82:3d:bb:d5:d6:ba 1 >>>>>> ...(snip)... >>>>>> >>>>>> mininet> h1 ping h2 >>>>>> PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. >>>>>> From 10.0.0.1 icmp_seq=1 Destination Host Unreachable # not handled >>>>>> as >>>>>> sleeping >>>>>> From 10.0.0.1 icmp_seq=2 Destination Host Unreachable >>>>>> From 10.0.0.1 icmp_seq=3 Destination Host Unreachable >>>>>> From 10.0.0.1 icmp_seq=4 Destination Host Unreachable >>>>>> From 10.0.0.1 icmp_seq=5 Destination Host Unreachable >>>>>> From 10.0.0.1 icmp_seq=6 Destination Host Unreachable >>>>>> From 10.0.0.1 icmp_seq=7 Destination Host Unreachable >>>>>> From 10.0.0.1 icmp_seq=8 Destination Host Unreachable >>>>>> From 10.0.0.1 icmp_seq=9 Destination Host Unreachable >>>>>> 64 bytes from 10.0.0.2: icmp_seq=10 ttl=64 time=2005 ms >>>>>> 64 bytes from 10.0.0.2: icmp_seq=11 ttl=64 time=996 ms >>>>>> 64 bytes from 10.0.0.2: icmp_seq=12 ttl=64 time=0.170 ms >>>>>> 64 bytes from 10.0.0.2: icmp_seq=13 ttl=64 time=0.055 ms >>>>>> 64 bytes from 10.0.0.2: icmp_seq=14 ttl=64 time=0.059 ms >>>>>> 64 bytes from 10.0.0.2: icmp_seq=15 ttl=64 time=0.066 ms >>>>>> ^C >>>>>> --- 10.0.0.2 ping statistics --- >>>>>> 15 packets transmitted, 6 received, +9 errors, 60% packet loss, time >>>>>> 14054ms >>>>>> rtt min/avg/max/mdev = 0.055/500.491/2005.751/765.266 ms, pipe 3 >>>>>> >>>>>> >>>>>> Please note that this approach will suspend "all" activities of Ryu, >>>>>> if >>>>>> a >>>>>> lot of >>>>>> Packet-In events curred while blocking, these event will invoked >>>>>> immediately. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Iwase >>>>>> >>>>>> >>>>>> >>>>>> On 2017年12月15日 06:03, Carlos Ferreira wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> I work with real switches (Zodiac FX). >>>>>>> >>>>>>> Depending on the Events, wether is Packet_In or other Events, I want >>>>>>> to take different kinds of actions. >>>>>>> Some of these actions, require contacting a different system >>>>>>> component, outside of the Ryu scope. >>>>>>> What I want, is to have a way to suspend the greenlet execution and >>>>>>> continue with the following Events processing, while the outside >>>>>>> system does its thing. Once the outside system returns with the >>>>>>> required data, the greenlet will resume the processing. >>>>>>> >>>>>>> Carlos >>>>>>> >>>>>>> >>>>>>> On 14 December 2017 at 20:37, <marcosab...@inf.ufg.br> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> When you subscribe an event (with @override) while switch is connect >>>>>>>> you >>>>>>>> receive this event. You can ignore these events implementing a logic >>>>>>>> according your application. But when you ignore an event, for >>>>>>>> exemple >>>>>>>> Packet_IN, you loss the packets that enter in switch. >>>>>>>> >>>>>>>> Can you explain more your problem? You work with real switch or OVS? >>>>>>>> >>>>>>>> Citando Carlos Ferreira <carlosmf...@gmail.com>: >>>>>>>> >>>>>>>>> Hello to all! >>>>>>>>> >>>>>>>>> Is it possible to suspend a Ryu Coroutine event? For example, >>>>>>>>> suspend >>>>>>>>> the execution of the Packet_IN handler, while waiting for an event, >>>>>>>>> signal or condition? >>>>>>>>> >>>>>>>>> I need to know how can I do this, because I need to execute some >>>>>>>>> algorithms, which may take some time and depend upon resources >>>>>>>>> outside >>>>>>>>> of the application. I wanted for the coroutine to wait until it >>>>>>>>> gets >>>>>>>>> a >>>>>>>>> result, but I didn't want to stall the entire event pipeline. >>>>>>>>> >>>>>>>>> Thank you! >>>>>>>>> Carlos Ferreira >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>> Check out the vibrant tech community on one of the world's most >>>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>>>>>> _______________________________________________ >>>>>>>>> Ryu-devel mailing list >>>>>>>>> Ryu-devel@lists.sourceforge.net >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> Check out the vibrant tech community on one of the world's most >>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>>>>> _______________________________________________ >>>>>>>> Ryu-devel mailing list >>>>>>>> Ryu-devel@lists.sourceforge.net >>>>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Check out the vibrant tech community on one of the world's most >>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>>>> _______________________________________________ >>>>>>> Ryu-devel mailing list >>>>>>> Ryu-devel@lists.sourceforge.net >>>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> Ryu-devel mailing list >>>> Ryu-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel >>>> >>> > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
