Files
NE_YuR/openflow/GEMINI.md
2025-11-12 08:14:29 +08:00

41 lines
2.2 KiB
Markdown

# Project Overview
This project is an OpenFlow agent written in C. It implements a subset of the OpenFlow 1.3 protocol to allow a remote controller to manage a network switch. The agent is designed to run on an ARM-based device.
The core logic resides in `main_user_openflow.c`, which handles various OpenFlow message types such as `HELLO`, `FEATURES_REQUEST`, `GET_CONFIG_REQUEST`, and `PACKET_OUT`. The agent responds to these messages by sending back appropriate replies, allowing the controller to inspect and manage the switch's state.
The project is built using a `Makefile` and links against several local libraries, including `libofp` (for OpenFlow protocol handling) and `libnet` (for network packet manipulation).
# Building and Running
## Building
To build the project, you can use the provided `Makefile`. The `Makefile` uses the `arm-linux-gnueabihf-gcc` cross-compiler, so you'll need to have that installed and in your `PATH`.
```bash
# To build the project
make
```
This will create an executable file named `user_openflow` in the project's root directory.
## Running
The `user_openflow` executable can only be run on the target ARM device. Based on the comment at the end of `main_user_openflow.c`, the following command can be used to run the agent:
```bash
sudo ./user_openflow -c eth0 -i obx0,obx1,obx2,obx3
```
* `-c eth0`: Specifies the control interface.
* `-i obx0,obx1,obx2,obx3`: Specifies the data plane interfaces.
The agent will then listen for incoming connections from an OpenFlow controller.
# Development Conventions
* **Coding Style:** The code follows a C-style with a focus on clarity and modularity. Functions are well-documented with comments explaining their purpose, parameters, and return values.
* **Testing:** There is a Python script `openflow_flow-test.py`, which suggests that testing is done using Python scripts.
* **Dependencies:** The project relies on several pre-compiled libraries located in the `lib/` directory. Any new dependencies should be added there.
* **Architecture:** The main application logic is event-driven, with a central callback function that dispatches OpenFlow messages to their respective handlers. This makes it easy to extend the agent by adding new handlers for additional OpenFlow message types.