Exploring LocalConnection for C# and Flash

| 40 Comments

I bet you've never seen this before... I wrote a C# program that communicates with Flash over LocalConnection.

I can't give you a live demonstration because I don't want any to decompile the C# executable, but here's a link to a captivate demo showing it in action: Using LocalConnection to send data between C# and Flash.

In the demo I'm only sending string values, but you can send just about anything over LocalConnection. On the Flash end, just use LocalConnection like you normally would. On the C# end, I've created a LocalConnection class that behaves in a similar manner. In Flash I can call a C# method directly in this manner.. it's very handy actually.

Currently I have no plans to release this code (I'd like to get MM's blessing first before just putting it out there). If you know anything about operating systems and know how IPC works you can probably figure it out on your own though.

This opens up a whole new world of combining Flash and .NET. Next steps are to flesh out a decent API (mine is a little rough around the edges since the above demo was just a proof of concept), and then port the code to Linux and OS X as well. LocalConnection behaves differently on each operating system because, well, each OS does IPC in a different manner. The quest for the cross-platform Flash projector continues...

40 Comments

Amazing!
All the times I saw Flash integrated with a Windows app was through an embedded flash.

This is pretty interesting, you could build applications as windows services and build the frontends with Flash.

I'm looking fordward to see this running!

Regards
Pablo Costantini

That is very cool. For me I find it exciting to extend Flash in a similar way.

Wickedly done, Darron. That is really excellent.

Can you communicate with that from a .swf on a site (eg: versus a flash projector)? I'm assuming it's no different, really - more of a question of how the C# app would connect to the .swf.

It'd be nice to have a C#/.NET debugger interface that you could connect to, instead of the standard Flash projectors that people have been floating around...

Jason - yes, you can use this method to talk to any LocalConnection imaginable (from StandAlone playuers, from .swfs in a browsers, and even from .swfs in their own projectors). As long as you know the LocalConnection name you can connect to it.

Actually, you don't *need* to know the LocalConnection name... in fact, I can write a program to look at all of the open LocalConnection's on my system and inspect the data going in and out of them.

So, if you use LocalConnection to send like passwords and other sensitive information, think twice. Make sure it's encrypted -- the information you send over LC is not as secure as you might think.

And also note, this is not limited to .NET. In C# I'm doing a lot of "extern" calls to kernel32.dll. I could've written this is C++, but chose C# because I think it better as a language and easier to develop in. On Linux and Mac I'll be using C++, or maybe Java and JNI.

This example could be converted into a runtime debugger pretty easily. Instead of trace, you would just create an lc and send the data to C#. Like.. out.send("debugger", "logError", theErrorData). That's a pretty good practical application.. let me think about that one (and trying to code it via Java). I doubt I'll have the time to write it though.

The idea of using the LocalConnection for inspecing objs and sending them to a Windows app sounds good.

I've made a Logger API some time ago that allows you to inspect objects and movieclips at runtime and send that information to multiple outputs. One of these outputs uses a LocalConnection obj and a Flash console. An example can be found here:
http://www.luminicbox.com/dev/flash/log/example.htm

The main issue i'm having right now is handling a large list of debugging items. A windows version of the console could improve performance and add some nifty features.

Maybe you can test something out, the logger API and flash console can be download from here:
http://www.luminicbox.com/dev/flash/log/luminicbox.log.zip
More information (in spanish) can be found here:
http://www.luminicbox.com/dev/flash/log/
he code, comments and class documentation is written in english.

Regards!
Pablo Costantini

now the real challenge would be to write a crossbrowser projector using localconnection to exchange data (maybe in python?).
if only macromedia would say yes...

Looks interesting :)

I'm using fscommand/setVariable for a desktop .NET application with embedded Flash UI and I wonder what are the advantages of LocalConnection in that case.

"crossbrowser projector"
d'uh.. ;)
should read crossplatform of course

Wow, I have recently run into a situation where we had discussed the feasability of doing exactly what you have accomplished. Our problem involves having a web based application communicate with a locally running (non-flash) piece of software. I know you said you would not be releasing the code any time soon, but is there any further information which you could divulge about what was involved in getting this to work?

I am mostly concerned with how you feel about the long term feasability of your solution, as this was an approach we were considering. Does it work smoothly? Do you feel like it's a hack that would fall apart with new versions of the flash player or with different configurations of windows? Do you believe the OSX conversion is going to be difficult?

We were planning on trying a socket connection first and seeing how that pans out, but a localconnection may be better.

@Rostislav - The advantage of using LocalConnection is that you can send data better and easier. With fscommand and sockets for external communication you have worry about serializing your data and such. With LocalConnection you just send the native object. I can send a native array from C# and Flash will pick it up as an array - no conversion necessary (it's part of the LC protocol).

@Claus - a Python port might be already underway..

@Noel - Long term feasability is not an issue. In Player 6 and 7, things will always work. In Player 8, LC might be implemented differently, but I don't envision it becomming not usable. There will have to be some coded added to check the version and make sure it's compatible. It works very smoothly, but right now it's kind of hacky because this was just a proof of concept. If I take time to flesh out a good API I would feel better about the stability. The OS X and Linux conversions should not be difficult at all, it's really just a matter of semantics. I know enough about IPC to know where to start looking, and the *concept* should be the same corss platform, with the implementation varying only slightly to support the different operating system system calls.

As to LC being better than a socket - the automatic serialization of data in LC beats sending text over a socket any day.

You could make your own version of Central with this ;)

Good stuff.

I don't know how LocalConnection works, but isn't this just a socket connection and sending commands back and forth (and you figured out the protocol)?

Manish, no it's definitely not a socket - it's a lot more complicated than that. We're talking low-level operating system stuff here...

so did you get a way through mutex & memory-mapped file...

just a guess...

-abdul

Sick bro! Just sick!

-erik

Wow ! Thats great ! I tried to figure out once whether it was done with Window messages, but did not detect any broadcasts when this kind of connections happened. Should I check again whether it is done with Window Messages or should I better try to figure out whether is is done by DDE ?
regards
Roberto

Awesome Darron! This make a lot of new things possible - great work, I know that can't have been easy : ).

@Roberto - no, it's not Windows messages and it's not by DDE.

@Robin - Yeah, it was a lot of fiddling trying to get it working. Reading data was kind of the easy part.. the *very* hard part was figuring out how to write data to the LC. That part alone I was stuck on for an incredibly long time. It actually came down to dumb luck (hey, the best inventions are usually by accident anyway, so maybe thats a good sign).

The possibilities for this are tremendous... It's so easy to use, and it's awesome to be able to call Flash methods directly from C#, and C# methods directly from Flash.. passing data between them is a breeze.

Now I hope MM has nothing against the reverse engeneering of LC (and will continue with LC in the next Flashplayer). In case of AMF, they were very tolerant, and OpenAmf was competing directly with their Remoting Product. But here I think MM has nothing to loose, but a lot to gain.
And I even more hope that you are going to reveal more info about how you did it or at least give us one more hint to make it a bit easier to figure it out ourselves.

I sincerely hope that something comes of this. This is immensely useful! We can stop worrying about data marshalling and get on with the cool stuff! This is Flex Remoting (easy as pie) for the desktop!

...

Hmm. Unfortunately for us, that sounds like something worth charging for.

Fingers crossed, thumbs held!

I think the people at 2entwine used Python to embed flash: http://www.2entwine.com/

their projector installs on MS, Linux, OsX

WOW, I have used fs command to communicate with my cocoa app, but will LocalConnection work better? Thanx

I've been looking through what you've said, I've got the names of the mutex and the shared memory, but any further than that and I'm stuck. I've got some code (C++) that looks like it should push a block of data into the right place and then signal the swf app to read it, but it doesn't work, I can't even get data from the swf app. Basically I'm stuck, what are the chances of any further hints?

That's fair enough. I'll just keep plugging away with what I know.

As the Swf format is an open format why should macromedia have a problem?

The swf format is open, yes, but the internals of how the Player implements LocalConnection is not.

Well now that you started the discussion it will eventually be revealed.

If I were you I would develop a component and sell it. If you don't someone else will and you will lose your first to market advantage.

it sounds verry nice.
but would it work on a pda?

for my final work i need to
send data (strings or is possible an array)
from c# to flash but i can't figure it out

kind regards
dennis

it sounds verry nice.
but would a localconnection
work on a pda?
(i don't know much flash)

im a master student and i'm searching
for sometway to communicate to flash
but i can't find it.

kind regards
dennis

I figured it out, but I am having trouble deserializing the method arguements if they are anything other than strings.. did you use .net deserialization, or create a custom class to resolve the arguements into .net types? I thought I had it figured out, as each block has a byte specifiying the length of the block -- until I started sending arrays and integers..

Hi,

Very nice work.

Did you ever get Macromedia's Blessing? I have just started to pursue a very similar line and would like to get a few things answered before getting any deeper.

Thanks

No, I still haven't received an "OK" to share the code I used to make this happen. :-(

great work and bad news ! :(

Great post!!.. Have you tried Flash with .NET 2.0 beta?

Lot of changes between 1.1 vs 2.0 in .NET..

Given that OSFlash has already released this information for C, I hardly think a C# implementation is going to break any hearts at Macromedia.

http://osflash.org/doku.php?id=localconnection

With ExternalInterface in Flash Player 8, there's no need to play with local connection like this anymore. :-)

real good but how can i use the same on mac? Can any one help me for the intigration of swf with cocoa app .

Thanx for reply

Honestly, I don't believe it. That's not a working demo. It's just a flash animation.

It's not a Flash animation, it's a Captivate demo. :-)

As I said before, ExternalInterface replaces the need to hack around with Local Connection like this. I wouldn't recommend using an LC approach to SWF Container communication.

Even though LC has been documented on OSFlash, I'm not planning on releasing my C# code for it now or in the future. There are better methods for communication, and I wouldn't recommend trying this approach anymore today.

Leave a comment



About this Entry

This page contains a single entry by darron published on March 17, 2005 9:16 AM.

Excellent article on using MTASC, ASDT for Development was the previous entry in this blog.

Happy Birthday to me! is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Archives

OpenID accepted here Learn more about OpenID
Powered by Movable Type 5.02