Caller vs Callee

AIDL behind the scene

Intro

As someone for whom English is a foreign language, I must admit that I always have a certain delay—a mental blockade, whenever the Caller and Callee are mentioned in the same context.

In the programming dictionary, the Caller is the one that registers and later invokes the callback, while the Callee is the one that provides the callback (or is callback itself), which will be invoked at the Caller's site.

A textbook example would be Publisher-Subscriber design pattern.

→More on that you can find on my GitHub blog: Observer implementation with modern C++

So far, so good.

But what about RPC—Remote Procedure Calls?

To simplify - it’s the way to invoke the functions (procedures) of another process, and eventually, to receive the result back.

Lets explore this on the Android - AIDL interface, as an example of IPC (Inter Process Communication), which employs under the hood Binder, a driver which is responsible for marshaling the data (including the custom specific one - Parcelables) across the process boundaries.

[[digression]] There are other Frameworks to define IPC as communication between at least two endpoints, like with yet another Google technology: gRPC/Protobuf. The Unix domain socket - is another classical approach, but requires much more manual work, especially for parsing the messages as raw bytes. REST is another way to demonstrate the RPC message flow, as HTTP request/response sent/received over WebSocket.

With AIDL interface, we defined the Service endpoint that is exposed to the Clients through the Proxy object. It's a one-directional communication, from Clients-to-Service: the Clients will invoke the RPCs of the single Service, which will land in the thread pool of the process hosting the Service (meaning that RPCs are thread-unsafe: resulting in calling the service's methods simultaneously from different thread-contexts).

Similarly, we can specify the Remote-Callbacks (RCs) Interface for Service-to-Clients asynchronous updates. The Service provides the registration/deregistration APIs.

The Clients, on the other hand, provide the client-specific implementation of these RCs. In the established terminology, we mark, for this direction, the Clients as Callees. The Service will now play the role of Caller—the one which registers the callbacks and broadcasts the updates to the all connected Clients by calling the matching RCs.

But unlike single-process (local) callback invocation, these callbacks, as RPCs, will be invoked at the Callee's, not the Caller's side: once again, they will be distributed into the thread pools of the processes hosting those Clients.

Makes sense?

Since picture worth a 1000 words - here is, the entire Service-Client IPC communication revisited.

Clients-to-Service

To make its interface thread-safe, the Service (Callee) implementation needs to serialize those asynchronous messages (enqueue them), that will be sent from different Clients (Callers) simultaneously - ending into the thread pool of the hosting process.

This can be accomplished:

• Implementing AOT (Active Object Thread) at the Service side (Java/Kotlin)

• Using the Android embedded way, with HandlerThread - the very same mechanism with Looper and Message Queue

• Forwarding the data over JNI to native counterpart: that implements the AOT (in C++)

Service-to-Clients

Service (Caller) will broadcast the message by invoking the very same Remote Callback (RC) at the connected Clients (Callees) side - their client-specific implementations. Although it's the same mechanism as with Clients-to-Service communication flow - relying on Binder to distribute these messages in the thread pool of the clients hosting processes, for this "1-to-N" scenario, this should be generally thread-safe way of calling RCs.

Especially, if we additionally serialize those asynchronous updates (like Sensor updates, or by attached device: smartphone driven updates propagated via native counterpart of the service, over JNI interface) at service side.

If you like the content, and want to read more on the SW design and SW development based on the real projects experience, please subscribe.

You can also find me at Linkedin: My Linkedin account

Feedback as usual, more than welcome.

---