On Thu, 16 Aug 2018 12:23:30 +0900, Le Quoc Khanh wrote: > > [1 <text/plain; UTF-8 (quoted-printable)>] > Hi IWAMOTO, > > Thank you for your answer but I still do not really get how the replies are > accumulated. I could not figure out where in the *'ryu.app.ofctl_rest.py > <http://ryu.app.ofctl_rest.py>'* the *self.waiters* was first created for > each MULTIPART_REPLY message that is divided into multiple messages. The
It is initialized from here. https://github.com/osrg/ryu/blob/d7d526ad21993646bfec68daca8c544ecce094bd/ryu/app/ofctl_rest.py#L316 ofctl is from: https://github.com/osrg/ryu/blob/d7d526ad21993646bfec68daca8c544ecce094bd/ryu/app/ofctl_rest.py#L268 As you are using OF1.3, you'll get here: https://github.com/osrg/ryu/blob/d7d526ad21993646bfec68daca8c544ecce094bd/ryu/lib/ofctl_v1_3.py#L461 waiters is set here: https://github.com/osrg/ryu/blob/d7d526ad21993646bfec68daca8c544ecce094bd/ryu/lib/ofctl_utils.py#L250 > *stats_reply_handler* just checks if the message for each FlowStatsReply > and if it was not in *self.waiters*, it just returns without doing > anything. The same happens if the message has the OFPMPF_REPLY_MORE flag > set to 1 which in my opinion should be appended to the > *self.waiters[dpid][msg.xid]*. I am sorry but there is almost no The existence of the flag bit doesn't affect if appending happens or not. The accumulated msgs are parsed in ryu.lib.ofctl_v1_3.get_flow_stats. > documentation in the source code so it looks quite cryptic. Additionally, > what the *lock* is and what is the purpose of using that? The lock is to let the thread which sent a flow stats request wait until all the replies are received. Do you get the idea? > For now, as my understanding, for each FlowStatsReply event, the msg.flags > need to be checked to see if it is a part of a MULTIPART_REPLY and that > more messages will come. If so, create a dictionary record with > the corresponding msg.xid for storing this message and keep appending the > subsequent messages with the same msg.xid until receiving the last message > then process them all at once. With that idea, I tried implementing a > simple app for obtaining flow stats from a single switch which looks like > the code below. It seems to work now but I am not sure if it is an > appropriate way for handling MULTI_REPLY message. Any suggestion would be > really appreciated. In this way, flow stats replies are processed in a different thread than the thread which sent a flow stats request. If that isn't a matter for you, it would be fine. > class FlowStatsCollector(app_manager.RyuApp): > > > > OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION] > > > > def __init__(self, *args, **kwargs): > > super(FlowStatsCollector, self).__init__(*args, **kwargs) > > self.waiters = {} > > > > @set_ev_cls(ofp_event.EventOFPFlowStatsReply, MAIN_DISPATCHER) > > def flow_stats_reply_handler(self, ev): > > msg = ev.msg > > body = msg.body > > dp = msg.datapath > > > > if msg.flags & dp.ofproto.OFPMPF_REPLY_MORE: > > if msg.xid not in self.waiters: > > self.waiters[msg.xid] = [body] > > return > > else: > > self.waiters[msg.xid].append(body) > > return > > else: > > if msg.xid in self.waiters: > > msgs = self.waiters[msg.xid] > > msgs.append(body) > > del self.waiters[msg.xid] > > else: > > msgs = [body] > > > > for body in msgs: > > for flow in body: > > # process each flow stats > > pass > > > Kind regards, > Quoc Khanh > > > > > On Wed, Aug 15, 2018 at 7:20 PM, IWAMOTO Toshihiro <iwam...@valinux.co.jp> > wrote: > > > On Tue, 14 Aug 2018 08:08:03 +0900, > > <quockhanh...@gmail.com> wrote: > > > > > > [1 <multipart/alternative (7bit)>] > > > [1.1 <text/plain; utf-8 (quoted-printable)>] > > > Hi all, > > > > > > I am developing a flow monitoring app using FlowStatsRequest/Reply. > > However, when the number of flows on switch exceed 682, the switch start > > breaking the data into MULTIPART_REPLY message and send back to the > > controller as a sequence of FlowStatsReply with the same msg.xid and the > > OFPMPF_REPLY_MORE flag set to 1 (except the last one). My question is how > > can I reassemble these FlowStatsReply messages into a single one so I can > > process it as a normal FlowStatsMessage. I already read this implementation > > in ‘ofctl_rest.py’ (https://github.com/osrg/ryu/blob/master/ryu/app/ofctl_ > > rest.py#L749) but could not understand it. > > > > Replies are accumulated into self.waiters. When the last reply message > > arrives, the function sends a ryu.lib.Event, which resumes execution > > in ryu.lib.ofctl_v1_3.get_flow_stats (or any other OF version). > > > > For another implementation, see ryu.app.ofctl.service. > > > > > > > In addition, in case of some FlowStatsReply messages in a sequence are > > lost or the last message in the MULTIPART_REPLY message never arrive to > > controller, how can I detect it and handle it properly. > > > > If the last message is lost, ryu should raise a timeout exception. > > As the OpenFlow is over a reliable communication channel (TCP), I > > think we don't need to consider the case where packets in the middle > > are lost. > > > > -- > > IWAMOTO Toshihiro > > > > > > -- > *Quoc Khanh Le* > Swinburne University of Technology > +61450862991 > <http://www.linkedin.com/in/quockhanhdn> > <http://www.facebook.com/quockhanh.dn> > [2 <text/html; UTF-8 (quoted-printable)>] ------------------------------------------------------------------------------ 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
