Sending unmetered one way calls back and forth produces a simple design, but there are potential pitfalls: what if the server is much slower at processing updates than the client sends them? For example, the client may load a drawing consisting of many thousands of lines from some text file, and try to send them all sequentially. How can we apply back pressure to the client to prevent the server from being overwhelmed by this wave of updates?

By using the acknowledgement pattern and making the one way call AddLine(...); into a two way AddLine(...) -> ();, we can provide feedback to the client. This will allow the client to throttle its output as appropriate. In this example, we'll simply have the client wait for the ack before sending the next message it has waiting, though more complex designs could send messages optimistically, and only throttle when they receive async acks less frequently than expected.

Note: The source code for this example is located at //examples/fidl/new/canvas/diff_1. This directory includes tests exercising the implementation in all supported languages, which may be run locally by executing the following from the command line: fx set core.x64 --with=//examples/fidl/new:tests && fx test canvas_add_line_metered.

First, we need to define our interface definitions and test harness. The FIDL, CML, and realm interface definitions set up a scaffold that arbitrary implementations can use:

Client and server implementations can then be written in any supported language: