### Build and Install libfluid_base Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/QuickStart.md Navigates to the libfluid_base directory, configures the build with a /usr prefix, then compiles and installs the libfluid_base library, which handles the OpenFlow control channel. ```shell $ cd libfluid_base $ ./configure --prefix=/usr $ make $ sudo make install ``` -------------------------------- ### Build and Install libfluid_msg Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/QuickStart.md Navigates to the libfluid_msg directory, configures the build with a /usr prefix, then compiles and installs the libfluid_msg library, which provides classes for building and parsing OpenFlow messages. ```shell $ cd libfluid_msg $ ./configure --prefix=/usr $ make $ sudo make install ``` -------------------------------- ### Build and Run libfluid Sample Controller Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/QuickStart.md Changes the current directory to the examples/controller, builds the 'msg_controller' sample application, and then executes it with the 'l2' argument, demonstrating a basic OpenFlow controller. ```shell $ cd examples/controller $ make msg_controller $ ./msg_controller l2 ``` -------------------------------- ### Install libfluid Dependencies on Ubuntu Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/QuickStart.md Installs necessary build tools and libraries like autoconf, libtool, build-essential, pkg-config, libevent-dev, and libssl-dev using apt-get on an Ubuntu 12.04 system. ```shell $ sudo apt-get install autoconf libtool build-essential pkg-config $ sudo apt-get install libevent-dev libssl-dev ``` -------------------------------- ### Build and install libfluid switch for Mininet integration Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/examples/switch/README.md Compiles and installs the libfluid switch, making it discoverable by Mininet. This step is necessary after replacing Mininet's core files and before starting Mininet with the custom switch. ```sh $ sudo make $ sudo make install ``` -------------------------------- ### Prepare OFTest environment for libfluid switch Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/examples/switch/README.md Executes a setup script (`run_switch.py`) that creates virtual interfaces required by OFTest and starts the libfluid switch with these created ports, preparing the environment for testing. ```sh $ sudo ./run_switch ``` -------------------------------- ### Clone and Bootstrap libfluid Repository Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/QuickStart.md Clones the libfluid repository from GitHub, navigates into the cloned directory, and runs the bootstrap script. The bootstrap process fetches and checks out stable versions of libfluid_base and libfluid_msg. ```shell $ git clone https://github.com/OpenNetworkingFoundation/libfluid.git $ cd libfluid $ ./bootstrap.sh ``` -------------------------------- ### Compile and Run Java Learning Switch Example Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/examples/java/README.md This snippet provides shell commands to compile the Java bindings and run the `LearningSwitch` example. It assumes that `libfluid_base` and `libfluid_msg` are installed with the `/usr` prefix, and that Swig 2.0 and a compatible JDK (e.g., `openjdk-7-jdk`) are available. The `LD_LIBRARY_PATH` is set to ensure the Java application can find the native `libfluid` libraries at runtime. ```sh $ make $ LD_LIBRARY_PATH=./fluid:$LD_LIBRARY_PATH java LearningSwitch ``` -------------------------------- ### Run Mininet with Remote Controller and Test Connectivity Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/QuickStart.md Starts a Mininet network topology (tree, depth 2, fanout 2) configured to connect to a remote OpenFlow controller at a specified IP address and port. After the network is up, it pings all hosts to verify connectivity and dumps OpenFlow flows to inspect controller interaction. ```shell $ sudo mn --topo tree,depth=2,fanout=2 --controller=remote,ip=[IP],port=6653 mininet> pingall mininet> dpctl dump-flows ``` -------------------------------- ### Build libfluid switch application Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/examples/switch/README.md Compiles the libfluid switch application using the provided Makefile after all dependencies have been installed. ```sh $ make ``` -------------------------------- ### Install libcap-dev for libfluid switch Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/examples/switch/README.md Installs the `libcap-dev` package, which provides development headers for the pcap library, a prerequisite for building the libfluid switch on Ubuntu 12.04. ```sh $ sudo apt-get install libcap-dev ``` -------------------------------- ### Build and Run libfluid Python Bindings Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/examples/python/README.md This snippet provides the shell commands to compile the libfluid Python bindings and execute the OpenFlow 1.0 example application. Ensure all prerequisites like `libfluid_base`, `libfluid_msg`, Swig 2.0, and Python development headers are installed before running these commands. ```sh $ make $ python of10switch.py ``` -------------------------------- ### Reinstall Mininet with custom files Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/examples/switch/README.md Reinstalls Mininet using its `install.sh` script with the `-n` flag, after replacing core Mininet files with custom ones from `MininetFiles` to integrate with the libfluid switch. ```sh $ sudo ./util/install.sh -n ``` -------------------------------- ### Run libfluid switch with specified interfaces Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/examples/switch/README.md Starts the libfluid switch application, specifying the network interfaces (`veth0`, `veth2`, `veth4`, `veth6`) to be used as OpenFlow ports. Requires root privileges as interfaces will be set to promiscuous mode. ```sh $ sudo ./switch -i veth0 veth2 veth4 veth6 ``` -------------------------------- ### Start Mininet with libfluid switch and remote controller Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/examples/switch/README.md Launches Mininet with a single 3-host topology, enabling MAC address display, and configuring it to use the `fluid` switch type. It also specifies a remote controller at `127.0.0.1:6653`. ```sh $ sudo mn --topo single,3 --mac --switch fluid --controller=remote,ip=127.0.0.1,port=6653 ``` -------------------------------- ### Build and Run Floodlight Controller Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/Benchmarks.md Commands to compile the Floodlight controller using `ant` and then execute its main shell script to start the controller. ```Shell ant ./floodlight.sh ``` -------------------------------- ### Build and Run libfluid OpenFlow Controllers Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/examples/controller/README.md This snippet provides the shell commands to compile and execute the various OpenFlow controller implementations (raw, secure, loci) built with libfluid. It demonstrates how to use `make` to build the controllers and then run them, specifying the application type (e.g., `l2`) where applicable. ```sh $ make controller $ make raw_controller $ make secure_controller $ make loci_controller $ ./controller l2 $ ./raw_controller l2 $ ./secure_controller $ ./loci_controller ``` -------------------------------- ### Run libfluid switch with interfaces and custom datapath ID Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/examples/switch/README.md Starts the libfluid switch, specifying network interfaces and an optional custom datapath ID (`0x0000000000000001`). If not provided, a random datapath ID will be generated. ```sh $ sudo ./switch -i veth0 veth2 veth4 veth6 -d 0x0000000000000001 ``` -------------------------------- ### Execute basic OFTest cases for libfluid switch Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/examples/switch/README.md Runs a series of fundamental OFTest cases (Echo, PacketIn, PacketOut, FlowMod) to verify the basic functionality of the libfluid switch. These commands are executed from the OFTest directory. ```sh $ sudo ./oft basic.Echo $ sudo ./oft basic.PacketIn $ sudo ./oft basic.PacketOut $ sudo ./oft basic.FlowMod ``` -------------------------------- ### Test OpenFlow Controller Performance with cbench Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/examples/controller/README.md This command demonstrates how to use `cbench` to test the performance of the OpenFlow controllers. It specifies the target host, port, message count, and other parameters for a comprehensive benchmark, allowing users to measure the controller's throughput and latency. ```sh $ cbench -c localhost -p 6653 -m 1000 -l 10 -s 16 -M 1000000 -t ``` -------------------------------- ### Configure Floodlight Worker Threads Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/Benchmarks.md Adds a configuration line to the `floodlightdefault.properties` file to specify the number of worker threads for the Floodlight controller. This example sets it to 8 threads. ```Properties net.floodlightcontroller.core.FloodlightProvider.workerthreads = 8 ``` -------------------------------- ### libfluid Simplified OpenFlow Controller Implementations Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/SubmissionRequirements.md This section describes various simplified controller implementations provided as examples within the libfluid project, showcasing different approaches to OpenFlow message building, connection handling, and architecture portability across platforms like Android. ```APIDOC Controller Implementations: raw: Description: cbench and OpenFlow 1.0 learning switch (l2) applications that build messages using C structs. secure: Description: Uses the raw learning switch application; demonstrates a controller handling secure and non-secure connections on different ports simultaneously. Tested with Open vSwitch. msg: Description: Implementation showcasing libfluid_msg; provides a cbench application and a learning switch that works simultaneously with OpenFlow 1.0 and 1.3 switches (l2). loci: Description: Based on the raw learning switch application, but uses Loxigen generated sources to build messages. android: Description: The msg controller compiled to run in Android (ARM), demonstrating architecture portability. An APK is available (Android 2.3+). ``` -------------------------------- ### OpenFlow Driver Integration with Virtual Switch Agent Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/SubmissionRequirements.md This requirement specifies the need to demonstrate the OpenFlow driver's integration into the OpenFlow switch agent for a virtual switch. An example (`switch`) is provided, which simulates a switch and uses `libfluid_base` as a client. ```APIDOC Requirement: The submission must demonstrate the ability to integrate the driver into the OpenFlow switch agent for a virtual switch. Example: Name: switch Description: Simulates a switch and passes some basic OFTest tests. Client Implementation: Adapts libfluid_base to act as an OpenFlow client (rather than server/controller). Adaptability: Can be adapted to run in either physical or software switches. ``` -------------------------------- ### Third-Party Library License Compatibility Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/SubmissionRequirements.md This requirement specifies that if the submission depends on third-party libraries, their licenses must not prevent or limit ONF from distributing the entrant’s code. It provides examples of compatible licenses for common dependencies like libevent and OpenSSL. ```APIDOC Requirement: If the submission depends on third-party libraries, the license(s) on those libraries must not prevent or limit ONF from distributing the entrant’s code. Dependencies: libevent: BSD/Apache licensed. OpenSSL: BSD/Apache licensed. ``` -------------------------------- ### Integrate Google Analytics Tracking Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/header.html This JavaScript snippet initializes Google Analytics for web page tracking. It loads the analytics.js library using an immediately invoked function expression (IIFE), then configures a tracker with a specific Universal Analytics (UA) ID and sends an initial pageview hit. This setup is crucial for monitoring website traffic and user engagement. ```JavaScript (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', 'UA-48360026-1', 'opennetworkingfoundation.github.io'); ga('send', 'pageview'); ``` -------------------------------- ### Initialize libfluid Bundle Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/README.md This command executes the `bootstrap.sh` script, which is responsible for initializing the entire libfluid bundle. This typically involves cloning and setting up both the libfluid_base and libfluid_msg libraries, preparing the environment for development. ```Shell bootstrap.sh ``` -------------------------------- ### Initialize and Clear TLS for libfluid OFServer Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/examples/controller/secure/README.md This C++ code snippet demonstrates the essential steps to enable and manage TLS for a libfluid OFServer instance. It shows how to initialize the TLS library with paths to the controller's certificate and private key, and the switch CA certificate. Subsequently, it illustrates creating an OFServer instance with the 'secure' flag set to true, ensuring all connections are secured with SSL. Finally, it includes a call to clear allocated TLS resources. ```C++ using namespace fluid_base; libfluid_tls_init("/path/to/ctl-cert.pem", "/path/to/ctl-privkey.pem", "/path/to/ovs/pki/switchca/cacert.pem"); OFServer srv("localhost", 6653, 2, true); [...] libfluid_tls_clear(); ``` -------------------------------- ### Run raw Controller Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/Benchmarks.md Executes the 'raw' controller. It is typically built with `-ltcmalloc -O3` flags. An optional application argument `[app]` can be provided. ```Shell ./raw_controller [app] ``` -------------------------------- ### Bootstrap libfluid for Development Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/RepositoryGuidelines.md Executes the `bootstrap.sh` script with the `dev` flag, which configures the `libfluid` repository to use the `master` branches of `libfluid_base` and `libfluid_msg` instead of stable releases. This is useful for developers working on the core libraries. ```Shell $ ./bootstrap.sh dev ``` -------------------------------- ### Execute cbench for Controller Latency Test Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/Benchmarks.md Runs the cbench tool to compare the latencies introduced by different OpenFlow controllers, including libfluid, while running a learning switch application. The test simulates 16 switches, 10,000 messages, and 1,000,000 MACs, with results indicating latency in milliseconds. ```Shell cbench -c localhost -p 6653 -m 10000 -l 16 -s 16 -M 1000000 ``` -------------------------------- ### Execute cbench for Network Size Performance Test Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/Benchmarks.md Runs the cbench tool to assess how libfluid_base's performance scales as the network size increases. The test uses the 'raw' controller with 8 threads, simulating varying numbers of switches (1 to 1000) and a reduced number of MACs (100,000) per switch to prevent thrashing. ```Shell cbench -c localhost -p 6653 -m 10000 -l 16 -s 16 -M 100000 -t ``` -------------------------------- ### Run msg Controller Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/Benchmarks.md Executes the 'msg' controller. It is typically built with `-ltcmalloc -O3` flags. An optional application argument `[app]` can be provided. ```Shell ./msg_controller [app] ``` -------------------------------- ### Execute cbench for Controller Throughput Test Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/Benchmarks.md Runs the cbench tool to measure the raw throughput of various OpenFlow controllers, including libfluid's 'raw' and 'msg' variations. The test simulates 16 switches, 10,000 messages, and 1,000,000 MACs, with results indicating flows per millisecond. ```Shell cbench -c localhost -p 6653 -m 10000 -l 16 -s 16 -M 1000000 -t ``` -------------------------------- ### Execute cbench for Threading Performance Test Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/Benchmarks.md Runs the cbench tool to evaluate how libfluid's performance (specifically libfluid_base via the 'raw' controller) varies with the number of threads. This test uses a 'cbench fast reply' application that responds to packet-in events with dummy flow mods, simulating 16 switches and 1,000,000 MACs. ```Shell cbench -c localhost -p 6653 -m 10000 -l 16 -s 16 -M 1000000 -t ``` -------------------------------- ### OpenFlow Driver Sample Controller Integration Requirement Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/SubmissionRequirements.md This requirement states that the submission must include a sample controller that demonstrates the successful integration of the OpenFlow driver. ```APIDOC Requirement: The submission must include a sample controller demonstrating the integration of the driver. ``` -------------------------------- ### OpenFlow Driver Optional Capabilities Implementation Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/SubmissionRequirements.md This section specifies that all optional OpenFlow protocol capabilities should be implemented, with explanations provided for any omissions. It notes that all capabilities are implemented except for UDP/DTLS support, with detailed reasons for its exclusion. ```APIDOC Requirement: All optional capabilities described in the OpenFlow protocol should be implemented, unless an explanation is provided for non-implementation. Implementation: All capabilities are implemented (as far as a driver's responsibilities go). Missing Feature: UDP/DTLS support. Reason for Omission: Unclear specification regarding datagram loss, lack of proper testing structure (software/hardware switches), and current libevent (used by libfluid_base) doesn't support UDP. ``` -------------------------------- ### OpenFlow Driver Mixed Environment Operation Capability Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/SubmissionRequirements.md This section describes the driver's capability to operate simultaneously against OpenFlow 1.3- and 1.0-compliant devices in a mixed environment. It highlights the implementation in `fluid_base::OFServer` and automatic version negotiation. ```APIDOC Capability: The driver must be able to operate in a mixed environment against OpenFlow 1.3- and 1.0-compliant devices simultaneously. Implementation: Component: fluid_base::OFServer Extensibility: Possible to extend up to maximum supported OpenFlow version (255). Example Reference: controller example (Controller.hh and msg/MsgApps.cc). Version Negotiation: Done automatically for the user (can be optionally disabled). ``` -------------------------------- ### Run NOX MT Controller with TCMalloc Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/Benchmarks.md Executes the NOX MT controller, preloading `libtcmalloc_minimal.so.0` for optimized memory allocation. The controller listens on TCP port 6653 and is configured to use 8 threads as a switch. ```Shell export LD_PRELOAD=/usr/lib/libtcmalloc_minimal.so.0 ./nox_core -i ptcp:6653 -t 8 switch ``` -------------------------------- ### OpenFlow Driver Learning Switch Functionality Requirement Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/SubmissionRequirements.md This requirement specifies that the submission must provide learning switch functionality when connected to an OpenFlow switch. This functionality can either be integrated directly with the sample controller or provided as a separate application. ```APIDOC Requirement: The submission must provide learning switch functionality (when connected to an OpenFlow switch), either integrated with the sample controller or as a separate application. ``` -------------------------------- ### Build libfluid Android Libraries Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/examples/android/README.md Executes the build script to compile libfluid and its dependencies for Android. This script handles the cross-compilation process for ARM architecture. ```Shell $ ./build_libs.sh ``` -------------------------------- ### OpenFlow Driver Multiple Simultaneous Connections Capability Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/SubmissionRequirements.md This section details the driver's intrinsic ability to support multiple simultaneous connections. It emphasizes that the driver is agnostic to the connection peer, with distinctions handled by controller implementations through standard OpenFlow mechanisms. ```APIDOC Capability: The driver must be able to support multiple simultaneous connections. Architecture: Intrinsic to the architecture; driver is agnostic to the connection peer. Distinction: Distinction between connection cases (e.g., another switch, second connection from same switch) is handled by controller implementations via normal OpenFlow mechanisms (features request). ``` -------------------------------- ### OpenFlow Driver Compliance with v1.3.1 and v1.0 Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/SubmissionRequirements.md This section details the requirement for the OpenFlow driver to comply with ONF core specifications for OpenFlow v1.3.1 and demonstrate backward compatibility to v1.0, ensuring interoperability with existing equipment and controllers. It confirms that the driver works simultaneously with both versions. ```APIDOC Requirement: The driver must be compliant with ONF core specifications for OpenFlow v1.3.1 and demonstrate backward compatibility to 1.0. Implementation: Works simultaneously with OpenFlow 1.0 and 1.3, compatible with existing tools and software/hardware. ``` -------------------------------- ### Proof of Legal Rights Assignment for Code Submission Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/SubmissionRequirements.md This requirement mandates that all entrants must be able to provide proof of their legal ability to assign rights to their code. It also notes that the current code does not include any third-party code that is not licensed accordingly. ```APIDOC Requirement: All entrants must be able to show proof that they can legally assign rights according to the above provision. Compliance: Our code does not include any third-party code that is not licensed accordingly. ``` -------------------------------- ### Forward Android Emulator Port for OpenFlow Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/examples/android/README.md Connects to the Android emulator's console via telnet and adds a redirection rule to forward TCP port 6653. This allows external OpenFlow switches to connect to the controller running on the emulator. ```Shell $ telnet localhost 5554 redir add tcp:6653:6653 ``` -------------------------------- ### Code Ownership and Rights Assignment to ONF Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/SubmissionRequirements.md This legal requirement states that the winning entrant must assign rights to the submitted code to ONF, which will then distribute the code under free and open-source licenses. This assignment is conditional on libfluid winning the competition. ```APIDOC Requirement: The winning entrant must assign to ONF rights to the code submitted. Distribution: ONF will distribute the code under free and open-source licenses. Condition: Will be done if libfluid wins the competition. ``` -------------------------------- ### OpenFlow Driver Integration with Physical Switch Agent Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/SubmissionRequirements.md This requirement mandates the demonstration of the OpenFlow driver's ability to be integrated into the OpenFlow switch agent for a physical network switch. ```APIDOC Requirement: The submission must demonstrate the ability to integrate the driver into the OpenFlow switch agent for a physical switch. ``` -------------------------------- ### Remove Description Columns from Directory Table (jQuery) Source: https://github.com/opennetworkingfoundation/libfluid/blob/master/doc/footer.html This jQuery snippet targets and removes table data cells (td) that have the class 'desc' and are nested within a table with the class 'directory'. This is typically used in web applications to hide or clean up specific columns from a tabular display, such as a file directory listing, without altering the server-side data. ```javascript $("table.directory td.desc").remove(); ``` === COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.