Skip to main content
These examples show the order of operations for a QMI request/response and indication exchange. They focus on the flow and ownership rather than specific service definitions.

​
Synchronous client request

A client creates a handle, connects to a service, and sends a request. The client waits for the response up to a timeout. The caller owns the request and response storage for the duration of the call. A successful transport return means that a response was received and decoded; service-level result fields still need to be checked. The flow is:
  1. Create a QMI handle with a callback for service events.
  2. Connect the handle to a service by service ID and instance ID.
  3. Send a request and wait for the response (up to a timeout).
  4. Check the response for success or failure.
  5. Destroy the handle when done.

​
Asynchronous client request

A client sends a request without waiting for the response. The response callback is called when the response arrives. The callback context should contain all state needed to complete the request. It must be released only after the callback runs or the request is cancelled according to the interface’s lifetime rules. The flow is:
  1. Create a QMI handle with a callback for service events.
  2. Connect the handle to a service by service ID and instance ID.
  3. Send a request with a response callback and private context.
  4. The callback is invoked when the response arrives.
  5. The callback processes the response and cleans up the context.
  6. Destroy the handle when done.

​
Service request handling

A service receives a request from a client. The service can process the request synchronously or save the request context and complete it later. The service must retain the request handle, client reference, and any decoded request state required to construct the response. Disconnect handling must cancel deferred work safely. The flow is:
  1. A client sends a request to the service.
  2. The service receives the request with a message ID and decoded data.
  3. The service processes the request (or saves it for later processing).
  4. The service sends a response using the request handle.
  5. The response is delivered to the client.

​
Indication delivery

A service sends an unsolicited event to a client. Indications do not consume a request transaction ID, and clients should be prepared to receive them between normal request/response operations. The flow is:
  1. A client registers to receive indications from a service.
  2. When an event occurs, the service sends an indication.
  3. The client receives the indication and processes it.
  4. The client can continue sending requests and receiving responses.

​
Optional fields

A descriptor can represent optional fields. The decoder must honor the incoming field presence and length information. Do not assume that fields arrive in a fixed order or that an optional field is present in every response. Unknown fields should be ignored when the service contract permits forward compatibility.