In my opinion, when compared to approaches like using Java or other OOP language to implement a driver/controller for specific cases. For example, I'm using Netty to manage the TCP connections for each OF Switch. Netty was chosen due to restrictions of the project where the controller will be used. I have to confess, in order to implement the OF messages, there's nothing better than simply allocating byte memory buffers and manipulating them directly. Since the OF specification already supplies a header file with many enumerations and structures declarations, life is simplified when implementing in C/C++. That did not happen to me with Java. I had to build from the ground, specific classes and hack through the Netty ByteBuf classes, in order for it to work exactly like I wanted. The code is not complex but I wasted lots of hours just to get the asynchronous communication to work decently and in parallel, with multiple OF Switches. In other words, be able to configure multiple switches in parallel without wasting system resources.
Since I have some experience in implementing Python Extensions in C and since there is an openflow.h to be used, IMHO I would recommend that approach. As always, I am open to other suggestions. My regards, Carlos On 10 April 2014 12:08, Christian Esteve Rothenberg < chest...@dca.fee.unicamp.br> wrote: > Hi Carlos, > > what do you mean with simpler? simpler compared to exactly which approach? > > Thx, > Christian > > On Wed, Apr 9, 2014 at 12:10 PM, Carlos Ferreira <carlosmf...@gmail.com> > wrote: > > I'm actually working on a Controller/Driver implemented in Java. Still, > > implementing C extensions for Python, in my opinion, is a simpler > approach. > > > > > > On 9 April 2014 03:49, Murphy McCauley <murphy.mccau...@gmail.com> > wrote: > >> > >> Sure, it's just the libfluid_experiment branch of the main fork: > >> http://noxrepo.org/git/pox/tree/libfluid_experiment > >> > >> It's definitely very much an experiment. ;) For starters, I was only > >> messing with 1.0 and while I used libfluid to read off the wire, the > >> responses are still generated with POX's OpenFlow library. I just > thought > >> it was worth experimenting to get a sense of what would be involved. > If you > >> guys are interested in doing much more work on this, we should talk! > >> > >> -- Murphy > >> > >> On Apr 8, 2014, at 5:34 PM, Christian Esteve Rothenberg > >> <chest...@dca.fee.unicamp.br> wrote: > >> > >> Thanks Murphy, > >> > >> one of my students working with POX wants to give a try and hopefullly > >> contribute to these efforts, can you share the pointers to that POX > >> branch. We can only say positive things about prototypiing with POX -- > >> giving it clean and effective OF1.3 support would be a neat upgrade > >> beneficial to all parties :) > >> > >> -Christian > >> > >> > >> > >> On Mon, Mar 24, 2014 at 10:17 PM, Murphy McCauley > >> <murphy.mccau...@gmail.com> wrote: > >> > >> > >> Congratulations. > >> > >> There's now POX branch that's been quickly hacked up to (sort of) use > >> libfluid's Python bindings. It also includes a minor patch for one of > the > >> swig .i files. > >> > >> -- Murphy > >> > >> On Mar 22, 2014, at 5:08 AM, Christian Esteve Rothenberg > >> <chest...@dca.fee.unicamp.br> wrote: > >> > >> Dear OpenFlow fellows, > >> > >> in case you are not aware about the public release of the winner > >> implementation of the OpenFlow driver competition > >> (https://www.opennetworking.org/competition) here is the pointer to the > >> github repository: > >> > >> http://opennetworkingfoundation.github.io/libfluid/ > >> > >> libluid may be interesting to developers of both OpenFlow switches and > >> controllers. It features support of OpenFlow 1.0 and 1.3, high > performance, > >> bindings to Python and Java, easy port to different hardware > architectures, > >> etc. > >> > >> We welcome users and developers interested in building an open community > >> to maintain libfluid as a useful, multi-purpose OpenFlow library to > develop > >> switch agents and controller implementations. > >> > >> -Christian (on behalf of the libfluid team) > >> _______________________________________________ > >> openflow-discuss mailing list > >> openflow-discuss@lists.stanford.edu > >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > >> > >> -- > >> Christian > >> > >> > >> > >> > >> > >> -- > >> Christia > >> > >> > >> > >> _______________________________________________ > >> openflow-discuss mailing list > >> openflow-discuss@lists.stanford.edu > >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > >> > > > > > > > > -- > > > > Carlos Miguel Ferreira > > Researcher at Telecommunications Institute > > Aveiro - Portugal > > Work E-mail - c...@av.it.pt > > Skype & GTalk -> carlosmf...@gmail.com > > LinkedIn -> http://www.linkedin.com/in/carlosmferreira > > > > -- > Christian > -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - c...@av.it.pt Skype & GTalk -> carlosmf...@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
_______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
