Architecture
Understand how Suduxu is structured across server, clients, SDKs, and communication layers.
Architecture
Suduxu is a networked client-server system built for low-latency input exchange: applications (servers) talk to smartphones (clients) over the local network, through a native runtime that neither side has to manage directly.
The four layers
Host Application
Your game or tool. Starts the runtime, manages devices, and reacts to input via the Rust or Unity SDK.
Core Runtime
A native library (.dll / .so / .dylib) handling networking, pairing, and event dispatch behind a C FFI.
Client Devices
Phones that send input and sensor data, and receive vibration, audio, and theme updates.
Interface Layer
HTML or XML themes rendered on the client, defining how it looks and behaves as a controller.
Clients are identified by a server-assigned id and can optionally stream sensors, report battery/network state, and send screenshots.
Data flow
Input happens
The client performs input — a button press, joystick move, sensor reading.
It travels over UDP
Low-latency input is sent to the runtime over UDP; connection management and control messages use TCP instead.
The runtime emits an event
Client connects/disconnects, input, device state, and errors all surface through the same event system — EventBus in Rust, C# events in Unity.
The host reacts
The SDK delivers the event to your application, which can optionally respond with feedback: vibration, audio, or logs.
This split — UDP for real-time input, TCP for reliable control — is what keeps input latency low without sacrificing connection reliability.
Why this design
Separating the UI (client) from the logic (host), and input (UDP) from control (TCP), keeps latency low while staying extensible to new platforms and languages — Rust and Unity today, more bindings later.