Introducing… FlashLCS

The Blitz Agency does some cool stuff from time to time… One of them might be the LocalConnectionService for Flash, which project is a cool way of utilizing the LocationConnection without the intrinsic problems of the native LocalConnection… such as…

  • The build-in 40KB/s limitation on data passed through the connection.
  • One-Way-Only-Communication.

According to the creators of FLCS their solution has addressed and “solved” these “problems” by…

  • raising the bar to 30MB/s.
  • support synchronous calls with discrete return values on function calls.

However, reading their statement, I do have some initial concerns about the implementation.
First of all I could be a little concerned that performance would have taken a hit due to the supposed packaging structure I presume they have implemented in order to remove the 40KB/s limit… and I in general I’m a little concerned about the synchronous implementation seeing that the processing would have to be blocked until the value returns…and furthermore, its the web, we have all gotten used to asynchronous communication being the way of the web.
However, it might turn out the removed the the data limit by other means then a packaging structure and that they have not implemented two-way calls through synchronous calls, but some other mechanism and then I might have learned something new…

Anyways, check it out yourself…

The Open Source project at Google Code…

5 thoughts on “Introducing… FlashLCS

    1. Yes, I see… reading the documentation I suppose its quite obvious that they have merely applied a packaging structure which handles large packets by “dividing the send() requests into multiple commands, each with less than 40K of data.”
      Thanks for the pointer… I have still not gotten around to examining their implementation myself, so its great to get pointers…

      // Peter

  1. Actually the calls are not synchronous at all, LCS is implemented just as any other service. Every call to lcs results in an ASyncToken. Once the call and arguments have been sent through request and response buffers, the ASyncToken result handlers are called.

    There is an improvement I’d like to make however which would be fairly straight forward change and that’s round-robin style messaging and buffering. As it is, because of the bandwidth we can get, it doesn’t really affect any usage besides fairly complex messaging.

    1. Hi Evan,

      Thanks a lot for the clarification, it sounds good…. I can’t wait to get a chance to the take it for a spin.
      Working in an interactive agency using “disturbance” quite a lot in regards to online advertising, I’m always looking for improved ways of having SWF instances communicate so I hope to get a chance soon…

      Thanks again for the elaboration… I really should look into your implementation now that you have gone out of your way and made it open source.

      // Peter

  2. Also, FYI the limit to LocalConnection was 40KB-per-request. There was no way to “stream” data with LocalConnection without multiple requests of <40KB each. LCS just simplifies that process by doing the heavy lifting for you, by chopping up requests into <40KB chunks and buffering them on each side into a single request with a resulting speed of up to 30MB/s.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s