n Aug 10, 2012, at 2:28 PM, senthil arumugam wrote: > We plan to try with some code in the switch->controller side to pass some > vendor specifc data items. The corresponding application on controller would > use them to meet our intended functionaities. My understanding is that I can > use pythoon to build the application on the controller. This way, I thought > NOX can be a better framwork than POC since C++ can be used to handle vendor > speicfic data and Pytrhon is for our application. Also the same framwork used > by 'nox_gui.py' can be used to enhance our GUI! > Do you think my above assumption is not right since Verity does not support > Python, thus leaving only C++ as the option? > > If yes, do you recommend POX to build both openflow handler and application? > I understaning is that POX is used only for python, thus may not be suitable > for extending the openflow backend? > > If both are not recommended for our needs, can I stick to 'destiny' branch?
So in order to do what you want… With destiny: A) Extend OVS with your extensions B) Extend NOX's OpenFlow parsing/events in C++ to handle your extensions (you may be able to like… reuse the structs themselves, but reading it off the wire and stuff will be NOX-specific) B-2) Expose those extensions to Python using SWIG and/or Python/C++ glue code C) Write your controller applications in C++ and/or Python D) Extend the NOX GUI or write a web GUI With verity: A) Extend OVS with your extensions B) Extend verity's new OpenFlow parsing/events to handle your extensions C) Write your controller applications in C++ D) Write your own GUI With POX: A) Extend OVS with your extensions B) Extend POX's Python OpenFlow parsing/events to handle your extensions C) Write your controller applications in Python D) Extend the POX GUI (based on the NOX GUI) or write a web GUI Step A is always the same, so forget about it for now. Step B is pretty easy and straightforward in both verity and POX. Making support for extensions in POX cleaner is on the roadmap, but it's pretty easy as it is (if not particularly elegant). In contrast, B is somewhat more difficult in destiny, and you'll also have step B2 which is somewhat more difficult still (especially if you're not familiar with SWIG and Python's C API). While B may be fairly straightforward in verity, you end up writing your applications in only C++ for step C. In both destiny and POX, you could use Python. Finally, for step D, destiny and POX have some GUI stuff already built, as well as web backends for developing web UIs. It seems like you are under the impression that you'd be saving some effort because you could use the same C++ code to accomplish both steps A and B in destiny or verity. This probably is not true in a significant sense. Moreover, implementing the controller side in verity or POX is just straight up easier than in destiny. If *I* were doing this, I would absolutely use POX unless I was expecting to run the code in situations where performance truly mattered (e.g., I was planning on writing a very reactive application or an application did a lot of expensive computation), and in that case, I would absolutely use C++ in verity. You can stick to the destiny branch, but it is no longer actively maintained and you may find that at least those of us in the "NOXRepo team" are less enthusiastic about providing assistance. None of us use it anymore, and I think we all believe that pretty much all use cases are better addressed by verity or POX. Hope that helps. -- Murphy
