weixin_39801714
2020-12-29 13:44 阅读 0

pox starts applications on start?

Hello, using a single-switch topology and two hosts, I modified the l2_learning file to not install the rules when a packet_in is sent. So instead of sending a flow_mod, the controller sends a packet_out to the switch indicating the port of the destination host. The ping results between the two hosts range from 10 to 40-50 ms, can you tell me if this is possible? The results never stabilize but oscillate between these thresholds. I therefore raised the doubt, pox starts some other application in addition to that indicated in the command ./pox.py forwarding.l2_learning?

该提问来源于开源项目:noxrepo/pox

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

10条回答 默认 最新

  • weixin_40002009 weixin_40002009 2020-12-29 13:44

    Well, it sounds like your modified application is probably similar to the --reactive mode of the forwarding.hub component. So you might try that and see if it behaves the same.

    Why would you think the results you're seeing aren't possible?

    You might find results are more stable if you start POX with --unthreaded-sh (immediately after pox.py).

    点赞 评论 复制链接分享
  • weixin_39801714 weixin_39801714 2020-12-29 13:44

    It's not that I do not think it's possible, it's just that I tried the same module with other controllers and the results are more stable. For example with floodlight (the same module) the ping results as about 6 ms, Pox varies a lot between 10 and 50 and it seemed strange. I had given as an explanation the fact that pox is written in python and then loses some 'time because it is interpreted... I hope I did not say blasphemies, thank you very much for your answer. I try now with --unthreaded-sh and i let you know

    点赞 评论 复制链接分享
  • weixin_39801714 weixin_39801714 2020-12-29 13:44

    I performed the test with --unthreaded-sh and the result has definitely improved, now the values are stable. I wanted to ask you something about --unthreaded but I've seen you answer here http://pox-dev.noxrepo.narkive.com/rj7JPPhV/problems-with-multi-threaded-dos-in-pox. Another thing that I would like to ask you is: in hub mode it is the same as my module only with the single topology with two hosts, right? (If you tried forwarding.hub in reactive mode with a more complex topology, even with three hosts instead of two, the hub would flood all hosts, while mine sends to the specific port).

    点赞 评论 复制链接分享
  • weixin_40002009 weixin_40002009 2020-12-29 13:44

    Performance for reactive applications hasn't been a big priority. --unthreaded-sh usually helps, at least for latency. Without it, there's an extra thread switch before things like packet-in events get raised, and that can take a nontrivial and sort of nondeterministic amount of time due to how threads in Python work. Using Pypy instead of the normal Python interpreter may also help. But it's still Python, and reactive applications are still typically a bad idea.

    And yes, I think you've got it. The hub is like a learning switch that never learns. So while l2_learning should eventually stop flooding/packet-in'ing, the reactive hub won't. Makes it good for testing some things.

    Seems like this is resolved, so I'm going to close the issue, but feel free to reopen it if I've missed something.

    点赞 评论 复制链接分享
  • weixin_39801714 weixin_39801714 2020-12-29 13:44

    One last curiosity, so pox is a multithreaded controller for centralized architectures, is that correct? I ask because I understood it was not multithreaded

    I take this opportunity to thank you for the help, you were very kind

    点赞 评论 复制链接分享
  • weixin_40002009 weixin_40002009 2020-12-29 13:44

    I wouldn't say that's correct. In terms of threading...

    POX itself doesn't use threads for performance reasons. There's hardly such a thing as threads for performance in Python. POX may use a couple threads in some places for design/organization/convenience reasons. Indeed, it almost certainly uses at least one extra one (for IO, as mentioned) unless you're using --unthreaded-sh. This alters performance characteristics (e.g., the change in latency you observed), but that's not why it was done this way. It was both a structural/design decision and it can be convenient in a number of cases (e.g., using POX with foreign event loops). But in lots of cases isn't really necessary (hence the ability to turn it off).

    But that's just POX itself. When you write components, there's nothing to force you to use threads or not to use them. Again, Python is likely to be the limiting factor here: using threads will generally not buy you computational performance (though it may buy you convenience or let you structure things in a way you like or avoid blocking with blocking APIs, etc.).

    POX does have some support for writing "cooperative tasks" via recoco, which is its own cooperative scheduler and "cooperative syscall" layer. This was a design point inspired by NOX. These are sort of like "green threads" or whatever you want to call them. The OpenFlow event handlers in POX are all called from such a cooperative task. This scheduler and the tasks in it are all run from a single actual thread. (This is why POX normally runs on two threads -- one for IO and another one for cooperative tasks; --unthreaded-sh jams the two of them together onto a single thread. I think if you want to be technical about it, those both normally run on new threads and the main thread just goes to sleep, so there's actually normally three? It's been a while...)

    In terms of centralization...

    POX is not limited to centralized architectures. None of the sample POX apps have any explicit distribution, but that doesn't mean you can't do it using POX. Indeed, parts of it may be at least slightly useful for implementing distribution. Here I'm specifically thinking that I believe there was a DHT implemented atop the POX messenger component at some point (and I was also thinking that the fangtooth branch had some support for gRPC, but looking at the repo, I guess that hasn't been pushed... yet?). But there's some good argumentation that in many cases, you probably shouldn't write explicitly distributed controllers even if you want a distributed controller -- see the SCL paper by Panda et al.

    点赞 评论 复制链接分享
  • weixin_39801714 weixin_39801714 2020-12-29 13:44

    Thank you so much for everything, I also hope that this post can be useful to others.

    点赞 评论 复制链接分享
  • weixin_39801714 weixin_39801714 2020-12-29 13:44

    Sorry , I wanted to ask you one last thing that is not clear to me. When starting pox, only the application I enter as an argument is started (for example, if I put ./pox.py forwarding.hub, it will only start hub), or are other default apps started? For example, do some lldp package send applications start? I ask because my intent would be to start only my application for testing ... thank you so much earlier

    点赞 评论 复制链接分享
  • weixin_40002009 weixin_40002009 2020-12-29 13:44

    It pretty much only starts what you tell it. I think the only exception to this is that if you start an application which depends on OpenFlow in an obvious way, it will automatically start the OpenFlow component so it can actually talk to switches without requiring you to start the OpenFlow component manually.

    Of course, components can also start other components explicitly, so it's always a possibility that one gets loaded that you weren't expecting. I don't think there are many examples of this in the components that come with POX, though, besides the ones in "samples"... several of which do basically nothing except launch other components (like samples.spanning_tree).

    点赞 评论 复制链接分享
  • weixin_39801714 weixin_39801714 2020-12-29 13:44

    Thank you so much again for your availability :)

    2018-05-22 16:46 GMT+02:00 Murphy :

    It pretty much only starts what you tell it. I think the only exception to this is that if you start an application which depends on OpenFlow in an obvious way, it will automatically start the OpenFlow component so it can actually talk to switches without requiring you to start the OpenFlow component manually.

    — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/noxrepo/pox/issues/206#issuecomment-391017780, or mute the thread https://github.com/notifications/unsubscribe-auth/APs5B9IX2PjO2Tm1mPrrRahl6tJEYwwkks5t1CSrgaJpZM4Tz99s .

    -- Distinti saluti Rold Luca Antonio

    点赞 评论 复制链接分享

相关推荐