Skip to main content
QRTR is a connectionless message-routing service that lets software components on the same processor or different processors exchange messages. It separates the addressing and service discovery from the physical transport, so a service can communicate without depending on one specific link.

QRTR architecture

The router core handles message routing, service discovery, and flow control. The transport interface abstracts away the details of the physical link (Shared Memory / RPM or another mechanism) so the router works the same way regardless of how data actually moves.

How clients and services communicate

  • Endpoints – Each client or service is identified by a node ID (which processor it runs on) and a port ID (which port on that processor). A service can also register a service name so clients can find it without knowing the exact port.
  • Service discovery – When a client needs to talk to a service, it looks up the service name. The router advertises which node and port the service is on, and the client can then send messages there.
  • Connectionless delivery – The router does not maintain a connection. Each message is independent, and the client must handle the fact that services can come and go, or move to a different port.
  • Message flow – A client sends a message to a destination port. The router consults its routing tables, forwards the message through the network, and delivers it to the destination. The destination can send a response or an event back.

Next steps

  • Architecture — Understand the router layers, routing tables, and network topology
  • Addressing — Learn how endpoints and services are identified
  • APIs — Use the kernel and socket interfaces to create ports and send messages
  • Operations — Manage power, synchronization, flow control, and diagnostics