Skip to content

RDKDEV-1794: Add firebolt-cpp-transport Documentation - #142

Open
gourivarma3 wants to merge 1 commit into
rdkcentral:developfrom
gourivarma3:feature/RDKDEV-1794
Open

gourivarma3 wants to merge 1 commit into
rdkcentral:developfrom
gourivarma3:feature/RDKDEV-1794

Conversation

@gourivarma3

Copy link
Copy Markdown

RDKDEV-1794
Reason for Change: To add Component Documentation for firebolt-cpp-transport.
Fix: Added the README documentation
Test Procedure: None

I have read the CLA Document and I hereby sign the CLA
Signed-off-by: gourivarma3 gouri_varma@comcast.com

Copilot AI balanced review requested due to automatic review settings October 9, 2026 10:21

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

Several documented connection, retry, callback-threading, and lifecycle behaviors do not match the implementation.

10 open findings
What changed in this PR

Adds comprehensive component documentation for the C++ transport library.

Changes:

  • Documents architecture, threading, lifecycle, call flows, and configuration.
  • Adds Mermaid diagrams and module interaction details.
File Description
docs/​README.md Adds component design and operational documentation.

🧠 Review effort: Balanced


💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread docs/README.md

The library is structured as a layered stack. The outermost layer (`IHelper` / `SubscriptionManager`) provides a type-safe, RAII-managed interface that maps SDK-level operations to JSON-RPC method names and typed JSON deserializers. Beneath that, `IGateway` owns the JSON-RPC protocol logic: it generates message IDs, correlates responses to outstanding requests, manages event listener registration, and runs a watchdog thread that enforces request timeouts. The innermost layer (`Transport`) owns the WebSocket connection using `websocketpp` with an Asio event loop and decouples received message payloads from protocol processing through an internal message queue.

Northbound callers interact only through the `IGateway` and `IHelper` abstract interfaces. Implementation types are kept internal; `GetGatewayInstance()` and `GetHelperInstance()` return stable references scoped to the process lifetime. All data flow through these interfaces is outbound toward the Firebolt gateway daemon.
Comment thread docs/README.md

The southbound boundary is a single outbound WebSocket connection to the Firebolt gateway daemon. The connection URL, retry policy, and timeout parameters are all supplied through the `Firebolt::Config` struct passed to `IGateway::connect()`.

The library holds in-memory state: the current connection handle, the pending request map, and the registered event callback list. This state is reset on `disconnect()`.
Comment thread docs/README.md
#### Threading Model

- **Threading Architecture**: Multi-threaded — four distinct threads collaborate to decouple I/O, message processing, event dispatch, and timeout enforcement.
- **Connection Thread**: Runs the WebSocket Asio event loop and handles connection open, close, fail, and message events. Invokes the `ConnectionChangeCallback` on the calling thread for the initial result; subsequent callbacks fire on this thread.
Comment thread docs/README.md
#### Platform and Integration Requirements

- **Build Dependencies**: `nlohmann-json` (JSON serialization), `websocketpp` (WebSocket transport), `boost` (Asio backend for websocketpp). At runtime, `boost-system` is required.
- **Gateway Availability**: The Firebolt gateway daemon must be reachable at the configured WebSocket URL before `IGateway::connect()` returns. The configurable retry policy (`reconnect_max_attempts`, `reconnect_delay_ms`, `connect_attempt_timeout_ms`) supports environments where the gateway starts after the calling process.
Comment thread docs/README.md

#### Runtime State Changes

During normal operation the library reacts to WebSocket close or fail events delivered by the connection thread. These events trigger the registered `ConnectionChangeCallback` with `connected = false`. Pending requests are resolved with `Error::NotConnected`. The watchdog thread continues running until `disconnect()` is called explicitly.
Comment thread docs/README.md

## Component Interactions

The library communicates with the Firebolt gateway daemon over a WebSocket connection. All interactions are client-initiated and outbound.
Comment thread docs/README.md

**Event Notification Flow:**

Incoming JSON-RPC notifications (messages without an `id` field) are matched by method name to registered callbacks. The matched callbacks are enqueued to the notification worker thread, which invokes them asynchronously.
Comment thread docs/README.md
Comment on lines +306 to +308
- **Error Handling Strategy**: All public API calls return `Firebolt::Error` or `Result<T>`. JSON-RPC error responses are parsed defensively, replacing missing or malformed fields with safe defaults. WebSocket transport errors are mapped to `Firebolt::Error` values. Timed-out requests are expired by the watchdog without disrupting the connection, and pending requests are cancelled gracefully on disconnect.
- Error mapping: `src/transport.cpp`
- Request timeout and disconnect cancellation: `src/gateway.cpp`
Comment thread docs/README.md
Comment on lines +337 to +339
| `reconnect_max_attempts` | `unsigned` | `0` | Number of additional connection attempts if the initial attempt fails. When set to `0`, a single connection attempt is made. Capped internally at 100. |
| `reconnect_delay_ms` | `unsigned` | `1000` | Delay in milliseconds between successive reconnect attempts. |
| `connect_attempt_timeout_ms` | `unsigned` | `10000` | Maximum time in milliseconds for a single connection attempt (DNS + TCP + WebSocket handshake) before it is aborted and counted as a failure. |
Comment thread docs/README.md

## Build-Time Configurations

The following CMake options are exposed as Yocto `PACKAGECONFIG` entries in the bb file and control library behaviour at build time:
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants