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
*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
documentation in the source code so it looks quite cryptic. Additionally,
what the *lock* is and what is the purpose of using that?
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.
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>
------------------------------------------------------------------------------
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
