macromedia flash flash remoting: I have the need to send server event messages to a flash program. I do not
want Flash to poll for the messages on the server. But rather for the (in
the case a C# server resident service) to fire a message off to Flash and
have it delivered via AMF to the remoting interace on the client.

The Flash program is running in the stand-alone environment. So it should be
able to receive messages.(I.e. it is not in IE).

You can build a wrapper around your swf in .net c# or purchase a 3rd party
projector utility to help with this. There are several ways to approach it
once you have the added power of a shell around the swf file

1.The way I would approach it is by building the functionality to have the c#
service communicate with the flash shell. The .net shell would call
setVariable() on the swf and set a variable. Inside the swf you would
watch(theVariable) and have flash react accordingly.
2. You can also build a local xml socket server and have the swf connect to
that socket server. In that way, the socket server could inform the swf
anytime it wants without polling.
3. You can use the LocalConnection object to load a swf and communicate with
your existing swf

HTH

Chafic
----
http://www.blinex.com
blog: http://www.rewindlife.com

I also would prefer #1. The issue is that I think this only works with
workstation based solutions. (there is an article by Mike Chambers (MM) at
the macromedia site, describing how to wrap the Flash ActiveX object in a C#
wrapper. But the consensus is that this works only on PCs.

Our needs are a bit tricker.

1. PPC2003 <-> server
2. Async messages (events) both originating at server and PPC.

We currently have a working solution that looks like this:

Flash <-- xmlsocket ---> C# proxy on PPC <-- TCP socket --> Server
application

The marshaling and serielization of messages is something we want to
minimize (latency). So we are wondering about replacing the xml socket with
AMF. And whether this would actually perform better (again, latency and cpu
usage on the PPC are the resources we want to conserve).

I will look into the LocalConnection again, but I am not sure it supports
bi-direction uni-directional messages (i.e. thigns that don't look like RPC,
but rather as a simple message).


[quoted text, click to view]