> ## Documentation Index
> Fetch the complete documentation index at: https://dragonwingdocs.qualcomm.com/llms.txt
> Use this file to discover all available pages before exploring further.

# QRTR Operations

> QRTR control path, power management, synchronization, diagnostics, and dependencies.

## End-to-end port behavior

The normal router behavior is:

1. Create a local port.
2. If the port serves a service, register its service and instance name.
3. Look up a remote service when its endpoint address is unknown.
4. Send messages to the resolved endpoint.
5. Receive messages together with source information.
6. Repeat lookup, send, and receive as required.
7. Unregister the service when the server stops.
8. Close the port.

```mermaid theme={null}
flowchart TD
    Create[Create port] --> Server{Server?}
    Server -- yes --> Register[Register service name]
    Server -- no --> Resolve[Resolve destination]
    Register --> Resolve
    Resolve --> Send[Send message]
    Send --> Receive[Receive with source address]
    Receive --> Event{Service or node event?}
    Event -- no --> Resolve
    Event -- yes --> Refresh[Refresh routing or service state]
    Refresh --> Resolve
    Resolve --> Stop[Unregister and close]
```

## Power management

The router prevents suspend while messages remain pending. It acquires a wakelock when work must be handled and releases it after pending messages are processed. A transport or client should not assume that queued data will survive a suspend unless the router has completed the relevant work.

## SMP and multi-core safety

The routing table, active-server table, and active-remote-port table are shared state. Mutexes and spinlocks protect updates and concurrent access. Client callbacks should not hold router locks while performing operations that can block or call back into the router.

## Flow control

Flow control is represented on the control path with request and confirmation messages. The router uses this path to coordinate whether a destination can accept more data. A client should treat a flow-control notification as a transport condition and avoid busy-looping sends while the destination is unavailable.

## Diagnostics

The router provides kernel log messages to help diagnose routing or service-discovery problems. Useful evidence includes:

* Local node and port identity
* Service and instance name
* Resolved destination address
* Node, server, and client status events
* Flow-control requests and confirmations
* Send and receive return values
* Transport link state

## Transport dependencies

The router does not implement a physical hardware driver. It depends on transport adapters that connect it to the underlying link. The documented stack contains:

1. A transport adapter such as shared-memory or bridge transport
2. The router core
3. The socket-to-router interface
4. The kernel socket layer
5. Platform support and the underlying link driver

The transport adapter provides packet movement; the router core provides addressing, routing, service discovery, and flow control.

## Failure boundaries

A useful failure boundary is the first layer that stops making progress:

| Symptom                           | First boundary to inspect                            |
| --------------------------------- | ---------------------------------------------------- |
| No node or service appears        | Transport registration and control path              |
| Service appears but lookup fails  | Service table propagation and name/instance values   |
| Lookup succeeds but sends fail    | Route selection, destination port, and flow control  |
| Sends succeed but receives stall  | Receiver queue, callback, and packet ownership       |
| Communication stops after restart | Node/server status handling and stale endpoint state |