Using LocalConnection Reliably

Following up on my previous post about changes to LocalConnection in AIR 1.5.2, I thought I’d post some further information about how LocalConnection operates. Although definitely in the realm of implementation detail, it’s critical to know if you want to use LocalConnection in a reliable fashion. To the best of my knowledge, the following applies to all versions of LocalConnection to date.

LocalConnection operates via a shared memory segment that contains a list of endpoints listening for messages, plus a buffer in which messages can be queued up. All clients using LocalConnection periodically poll the segment, removing any messages for which they are the recipient and enqueueing any new messages they wish to send.

Clients that exit gracefully will remove themselves from the endpoint list during shutdown. However, to avoid a crashed client clogging up the segment with undeliverable messages, endpoints (and associated messages) are timed out by the other clients. Basically, any client that finds old messages queued up, thus indicating an unresponsive endpoint, removes that endpoint and associated messages from the segment. “Old” is defined as a few seconds.

This heuristic for detecting crashed clients can be tripped up by clients that merely become unresponsive–i.e. are in a tight loop in ActionScript–for too long. When this happens, the client’s endpoint is closed even though the client itself is still running. After this, the client can no longer receive any messages destined for that endpoint. Note that there are two things that have to happen to get into this situation: the listener has (1) to be unresponsive for a “long” time while (2) simultaneously having LocalConnection messages sent to it.

Clearly, the implementation could be modified to avoid this issue, and you certainly shouldn’t depend on this behavior. Still, I hope that knowing about this issue might help you avoid it by keeping your applications responsive. Keeping applications responsive is, of course, a good thing in any case.

One Response to Using LocalConnection Reliably

  1. Tek says:

    Thank you for this post and still more for the one you are preparing, Oliver. ;)The behavior you describe here also exists in the Flash Player. I remember having looking into a bug that only few customers could reproduce. The result was of course that two independent applications couldn’t communicate. Finally we realize that one of the application simply became unresponsive on old computers during its initialization. Only the source of a LocalConnection reader utility on OSFlash website helps me to understand the problem: need to better understand LocalConnection internals. I hope that in the future Adobe will also increase the delay needed before considering the application unresponsive.