Does localConnection in flash player randomly fail sometimes?

Question

I have two flash movies communicating with each other using localConnection, passing an object from swfA to swfB. This seems to work fine, but will occasional fail. The only information we have is that the status event is fired with a level of error, there is no other information. Once a connection has failed it will continue to do so.

I don't know why it's happening but it is not a security problem (both movies are running on the same domain) and all communication is wrapped in a try..catch.

Has anyone ever seen this or can anyone suggest an alternative method for communicating between movies? I've tried using ExternalInterface but it's too slow for the number of updates that are sent.

Answer 1

LocalConnection is insane. It goes through your computer and communicates with clips globally. That means they don't even have to be on the same page. For example, if you had an air application running, you could communicate with the browser-based one.

Just remember that the ids are global, and they will error if they conflict. I've had this happen when I open the same swf twice (because it listens on the same id). This happens even if they are on separate pages.

Another option is to have your swfs poll the server and communicate through the database. Not sure if that helps at all. I try to avoid LocalConnection when I can :)

Answer 2

We seem to have fixed the problem but are not entirely sure why (we may just have greatly reduced the number of failures). We have implemented the following:

• Reduced the number of localConnections moving as everything to externalInterface where speed wasn't an issue
• Generated a globally unique id for each movie by appending a timestamp each time the page is refreshed (rather than re-using the same id). This seemed to reduce the occurrence of fails greatly (although they did still happen)
• Added '_' to LocalConnection id (see docs for why). Unsure if this helped but seems a good practise.
• Force a reconnect each time a fail occurs. Again, a good thing to implement to improve robustness but since no fails occur now this isn't responsible for directly fixing the bug.

So no conclusive fix it just seems together these solved the problem.