2.8 IrisRpc (RPC transport layer)

IrisRpc is the low-level protocol that allows Iris clients to connect to Iris servers and to exchange IrisRpc messages, which are used to make Iris function calls.

IrisRpc assumes a bi-directional byte stream between the client and the server. This section assumes a TCP connection is used, but any other bi-directional byte stream transport can be used instead, for example Unix pipes, or a serial line.

The version of the IrisRpc transport protocol that is described in this section is 1.0. This does not indicate an Iris interface version or a level of support for Iris functions. Support for Iris interfaces can be queried using instance_checkFunctionSupport().

In this section, the term client means an instance, for example a debugger, connecting to a running server, and server refers to, for example, the IrisTcpServer. The server represents the simulation executable. Multiple clients can connect to a server at any time.

The JSON RPC 2.0 specification uses the terms client and server to indicate the caller and callee, respectively. These semantics are not used in this documentation. An Iris client is both a JSON RPC 2.0 client and a JSON RPC 2.0 server. An Iris server is also both a JSON RPC 2.0 client and JSON RPC 2.0 server. Both clients and servers can send and receive functions calls.


  • The client and server side must both implement a JSON RPC 2.0 client and server. This is mandatory. This means both sides can call functions on the other side.

    Some functions in this documentation are called callbacks. This term refers to a function that is called in the other direction in a specific context. Callbacks are normal function calls.

  • All interactive clients should be able to receive callbacks. To receive callbacks, clients must use a persistent connection.
  • When a client disconnects, all its callbacks are automatically unregistered. The IrisTcpServer discards callbacks that should be sent to a disconnected client. This might happen if unregistering the callback was delayed.
  • Killing the model and killing a client are first-class operations and must be supported seamlessly.
This section contains the following subsections:
Non-ConfidentialPDF file icon PDF version101196_0100_00_en
Copyright © 2018 Arm Limited or its affiliates. All rights reserved.