asynchronous messaging as alternative to synchronous AiDL/IBinder

[Wink Saville]

I've been studying Android messaging and the recommendations
for communicating. Intents & IntentReciever allows components
(Activities) to communicate asynchronously using a publish/subscribe
style of communication.

But for 1 to 1 type communication Android provides an IPC which
uses AIDL and IBinder. This is an RPC style communication and
appears to be related to Java RMI. I find this tightly coupled/synchronous
interfaces inappropriate for some types of applications.

Personally, I would like to have the option of using asynchronous
messaging as an IPC. Basically, I'd like to accomplish the same goals
as AIDL/IBinder but using an asynchronous messaging.

Is anyone else interested in this?

Regards,

Wink Saville

[Zach Hobbs]

I think this would be useful as well...you can actually do it, but you can't
use AIDL to achieve it:
http://groups.google.com/group/android-developers/browse_thread/thread/378ce5eea6ffaee7

--

Zach Hobbs
HelloAndroid.com
Android OS news, tutorials, downloads

[Wink Saville]

Zach Hobbs wrote:
> I think this would be useful as well...you can actually do it, but you can't
> use AIDL to achieve it:
> http://groups.google.com/group/android-developers/browse_thread/thread/378ce5eea6ffaee7
>
>

Zach,

Here are some ideas, please add your thoughts!

Goals Asynchronous IPC:

*) Asynchronous
*) Messages sent by a single thread arrive in the same order as sent by
that thread
*) Messages sent by multiple threads arrive in undefined order
*) Connection oriented with support for multiple connections.
*) Sender identity is in the message
*) ID defining the interface and a Description Language
*) Status field and a flag that defines if a message needs a reply
*) Message sequence number and timeout

Clarifications of the above:

*) Asynchronous

Sending a message is always a non-blocking operation.
This means that a receiver can never directly cause
the sender to become unresponsive.

*) Messages sent by a single thread arrive in the same order as sent by
that thread

This means that the transport layer for the messages
is "reliable" and maintains the ordering. So UDP would
not be an approprite transport but TCP is.

*) Messages sent by multiple threads arrive in undefined order

If a component supports multiple simultaneous connections
there is no prescribe ordering can be assumed between the
connections. But as stated above the ordering within a
single connection is preserved.

*) Connection oriented with support for multiple connections.

To support multiple simultaneous connections add
Message.srcPort and Message.dstPort.

*) Sender identity is in the message

To allow for connections add a new field, Message.who,
which can be used as the Message.target field by a
component that recieves a message.

*) ID defining the interface and a Description Language

Currently the Int Message.what is too small of an address
space to uniquely identify each message I suggest an
additional field, Message.guid which is a globaly unique
ID. To guarrantee uniquness also create a repository for
registering the interface and assigning the unique ID.

*) Status field and a flag that defines if a message needs a reply

To allow for robust communication each message
includes a flag identifying if the sender expects
a reply. If this flag is set and the receiver/transport
knows the sender demands a reply and can send the reply
as well as a status indicating an error, such as "Unknown
Message" or "Transport Error, message not delivered".

*) Message sequence number and timeout

Adding a sequence number and timeout along with the
reply flag allows the application to know that a reply
will be returned even if the receiving component dies
or is otherwise unavailable.