![]() |
dfx 0.1.0
Linux-based dynamic dataflow executor
|
dfx is a Linux-only dynamic dataflow execution platform for building, running, and managing directed graphs of computational nodes that exchange messages asynchronously.
It targets users who care about explicit dataflow, runtime reconfiguration, process-level control, and low-level system integration - not monolithic pipelines or opaque schedulers.
Written in C++23, built on Linux primitives (epoll, Unix domain sockets, eventfd). Windows is not a target and never will be.
API documentation (Doxygen): doc.dfxengine.com
dfx is designed for scenarios where:
Typical use cases: stream processing, event pipelines, message routing and transformation, simulation, and experimentation with dynamic execution models.
| Concept | Description |
|---|---|
| Node | Stateful computation unit with named input/output ports. Executes one message at a time. |
| Port | Typed endpoint on a node. Inputs receive messages; outputs emit them. |
| Channel | Directed connection from one port to another. Defines message flow. |
| Graph | A collection of nodes and channels, loaded from a .dfx file. |
| Message | Typed payload flowing through a channel from one node to another. |
| Plugin | Dynamically loaded shared library that registers new node and transport types. |
Execution is fully asynchronous and event-driven. There is no global clock and no assumed execution order. Nodes run on a shared thread pool, with at most one thread active inside any given node at a time. The runtime prevents stack overflows in deep or cyclic graphs by bounding inline execution depth.
dfx is composed of four cooperating executables.
Loads a .dfx graph, wires nodes and channels, and runs the graph asynchronously. Exposes a Unix domain socket control interface for runtime inspection and modification.
Graphs can be modified at runtime - nodes added or removed, channels rewired - without stopping execution.
A long-running supervisor that spawns, monitors, and terminates dfx processes. Provides a stable control plane over a Unix domain socket. Does not execute graphs itself.
Each managed instance has its own graph, runtime state, control socket, and lifecycle. dfxd tracks all instances and applies restart policies independently.
The command-line interface for interacting with running dfx instances and the dfxd daemon. Stateless: each invocation connects, sends commands, receives a response, and exits - similar in spirit to docker or kubectl.
Subcommand groups:
| Group | Commands |
|---|---|
| node | list, get, add, remove |
| channel | list, get, add, remove |
| graph | export, validate, import |
| config | get, set |
| raw | Send raw protocol commands directly to a socket |
Examples:
A Qt6-based visual editor for authoring and inspecting dataflow graphs. Focuses on graph design, not execution.
Features:
Graphs authored with dfx-gui are saved in the standard .dfx format and can be executed directly by dfx.
The runtime uses:
Libraries (internal, also usable as Conan components):
| Library | Role |
|---|---|
| dfx-core | Base message, port, and node abstractions |
| dfx-runtime | Scheduler and execution engine |
| dfx-graph | Graph loader, controller, and node/transport factories |
| dfx-server | Unix domain socket server and command routing |
| dfx-fdwatch | epoll wrapper, signal handling, timer and FD watchers |
| dfx-plugins | Plugin registry and dynamic library loading |
| dfx-plugins-interface | C ABI used by plugin shared libraries |
| dfx-nodes | Built-in node implementations |
| dfx-client | Client library for connecting to a dfx or dfxd socket |
| dfx-pcapng | PcapNG capture and streaming for message tracing |
| dfx-subprocess | Subprocess management for dfxd |
| dfx-utilities | Logging, configuration, file-system helpers |
Graphs are stored as JSON with the .dfx extension. The format is straightforward:
Graphs can also be generated or inspected with dfx-ctl graph export/validate.
dfx supports dynamically loaded plugins (.so shared libraries). Plugins register new node types and transport types into the runtime at startup.
Plugin configuration lives in config.toml:
Plugins implement the C ABI declared in dfx-plugins-interface and are loaded via dlopen. The plugin registry outlives the scheduler to ensure no plugin code runs after dlclose.
A Wireshark dissector for the dfx control protocol is included in wireshark-dissector/.
dfx can capture the message flow of a running graph and emit it in PcapNG format, compatible with Wireshark and other packet analysis tools.
Named pipe (--trace-pipe) - one-shot only. A named pipe cannot signal a new connection, so the PcapNG header is only written once when dfx starts. If Wireshark is closed and reconnected, the header will be missing and the capture will fail. Use --trace-tcp for any scenario where you may need to reconnect.
| Requirement | Minimum version |
|---|---|
| Linux | (any modern kernel) |
| GCC | 13 |
| Clang | 16 |
| CMake | 3.21 |
| Conan | 2.0 |
| Qt | 6.0 (only for dfx-gui) |
To build without the Qt GUI:
To build without documentation (requires Doxygen by default):
Both dfx and dfxd accept a TOML configuration file (default: config.toml in the working directory, overridable with -c).
Command-line flags always take precedence over config file values.
Full API and architecture documentation is generated with Doxygen and available at:
The documentation covers all internal libraries, node and graph abstractions, the runtime control interface, and the IPC/daemon architecture.
To generate documentation locally (requires Doxygen and Graphviz):
dfx is released under the MIT License. See [LICENSE](LICENSE) for full details.
Copyright © 2025–2026 Vincent Leroy