Architecture
The following design goals and requirements were used as guiding principles:
- Dynamic and remote control of network components, including Wi-Fi access points.
- Ability to model realistic network environments for evaluation of network protocols, applications, and services.
- Cross-platform operation, including Windows, popular Linux distributions, and Android.
- Broad client usage across various languages, including but not limited to, C++, C#, and Java.
A client-server model is used as the basis of the architecture. The server or controlee device, either a local or remote host, exposes an API to control and communicate with the network components attached to it. The API exposes two main services: one for network component control and one for network data streaming. The client or controller device discovers controlee devices using multicast DNS (mDNS) and invokes the APIs to interact with the network components on the controlee system. The controlee system implements the API abstraction, providing adaption between neutral and API data structures.
The following diagram depicts the overall architecture:
On Linux, the host access point daemon (hostapd) is used to implement most of the Wi-Fi related functionality of the APIs. hostapd is a userspace daemon that enables regular Wi-Fi chipsets to be configured via software as access points (SoftAPs). A layer is implemented to adapt the nuetral type system of the upper layers to hostapd-specific types and concepts.
On Android, the architecture will closely match that of Linux as hostapd supports the platform.
On Windows, the architecture has yet to be devised but will likely closely match that of the Linux architecture in concept.
The component control architecture includes software components that adapt the APIs with "connectors" that implement the required functionality. In the case of Wi-Fi component control of access points, connectors are provided for both software-based access points (SoftAPs) and physical APs attached to the system.
The data streaming architecture includes software components that rely directly on gRPCs client, server, and bidriectional streaming capabilities. Hence, the architectural concepts are built directly into the API encoding and no adaption or platform-specific consideration is necessary. See the DataStreamingService API documentation for additional details.
To meet the cross-platform interoperability requirement, the API data structures are encoded with Protocol Buffers (protobuf) which provides native client bindings for many popular programming languages. To meet the remote execution requirement, the API data structures (protobuf messages) are surfaced with gRPC protocol buffer extensions (rpc, service) which provides remote procedure call semantics and IP addressing for the server component, hiding the API message transport. The following gRPC services are exposed¹:
| Service Name | Description | Documentation | Source |
|---|---|---|---|
| Component Control | APIs for network component control | NetRemote | NetRemoteService.proto |
| Data Streaming | APIs for data streaming between client and server | NetRemoteDataStreaming | NetRemoteDataStreamingService.proto |
¹: These services may be combined into a single gRPC service in the future.
See the API page for complete details.