Connecting flash to other computers (engineering)

[schreck425]

What is the best way to connect a computer running a swf to other computers? I'm working on flight simulators and I need a way to make menus that can update and receive information from a host computer (linux computer I believe) quickly. I know that actionscript can read a XML file repeatedly but I'm thinking that will have slow performance. Could I call a PHP, ASP file instead? I'll have to write and read information. Any ideas and advice would be much appreciated.

[hardyvoje]

just check
Working with external data
in Flash CS3 AS3 help

everything is there

[hardyvoje]

this is online version if you're not working with Flash IDE

http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000316.html


XML is slow because of web server response time and XML's UTF-8 text format where everything takse much bigger bandwidth than it is usally needed.

check this cool thing
http://aralbalkan.com/1026

[schreck425]

I'm not sure this is what I'm looking for. My connection will have no internet connection and just be on a local network without a domain with other linux computers. They're running an ancient language of fortran too. It looks like flash has a lot of security restrictions making you be on the same domain, but our network doesn't even have one. I looked at the Socket class, but still all examples seem to be flash to flash, instead of flash to something else. Do any of these classes connect with something other than XML or other flash applications?

[hardyvoje]

Yes, there are...


there is also IP connection (TCP) but I'll must have some data provider writen in some server side language....

I'm not using them but search this forum I've recently sow one post about it...

consider installation of PHP on server and PHP scripting, I would use that for server side, and there is some classes for DOM data communication for PHP and AS...

[sgartner]

I'm not sure this is what I'm looking for. My connection will have no internet connection and just be on a local network without a domain with other linux computers. They're running an ancient language of fortran too. It looks like flash has a lot of security restrictions making you be on the same domain, but our network doesn't even have one. I looked at the Socket class, but still all examples seem to be flash to flash, instead of flash to something else. Do any of these classes connect with something other than XML or other flash applications?

First, there is nothing inherently slow about XML over any other method of marshaling data that you are passing between computers. XML has a lot of positive value, not the least of which is consistency and human readability. When searching for developers to work on this or help, you will find no lack of XML expertise out there. ActionScript 3.0 has pretty nice support for XML as well.

You mention being worried about sending XML over and over to the flash, but if your data is constantly changing I don't see how you expect to be able to avoid sending that data over and over and it has to be encoded somehow to allow the client to parse through the data. You could create some kind of binary marshaling that might end up marginally faster, but since we are talking about a local area network (presumably at least at 10Mbs) I can't imagine how much data you would have to be sending before marshaling could hope to be the bottleneck in your system.

My advice is to not pre-optimize for things you don't yet know will be problems. Choose the method that is easiest to implement and easiest to maintain and only go a different way if that proves to be too slow. Make sure you encapsulate the marshaling in objects so that if you do decide you need to change it you only have to change the minimal amount of code.

Second, you had mentioned PHP or ASP in your first post, and then in this one you say that the servers only have Fortran on them? If you can do PHP or ASP with a web server, you will save yourself a lot of trouble just because the networking will be handled for you by the web server (and hopefully you meant ASP.net and not old ASP). If you need advice, PHP might be faster to mock something up quickly, but ASP.net gives you more choices for caching data in memory (as would Java Servlets).

There are lots of samples on the Internet showing communication between a PHP page and a flash client (and any of those methods should be easily translated to ASP.net or Java Servlets, etc. depending on which way you decide to go) and most of those samples will use XML. Since you have control of all servers, living within the sandbox shouldn't be an issue (and the lack of a host name isn't a problem, it will just use the IP addresses for the sandbox). The following page has information and samples about this:

Flash loading data across domains (http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_16520&sliceId=2)

Good luck.

[sgartner]

this is online version if you're not working with Flash IDE

http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00000316.html


XML is slow because of web server response time and XML's UTF-8 text format where everything takse much bigger bandwidth than it is usally needed.

check this cool thing
http://aralbalkan.com/1026

Hardyvoje,

You are mistaken in your assumptions about XML. XML has no direct tie to UTF-8 and can be encoded using one of a large number of character encoding schemes. If UTF-8 is not needed you can easily just use ASCII for your XML. Also, web server response time has absolutely no relationship to XML. You certainly can write crappy, slow, programs that generate XML, but you can also write snazzy, fast, programs that generate XML. There are millions of systems out there, that rely on optimal data transfer, which are based on XML. It sounds like you are letting a single experience determine your opinion of XML. I was the experience that was a problem, not the technology.

Note that I'm not trying to advocate that XML is a panacea either, but for what it is good at it does it quite well.