Communications with .SOL files

Question

I have created a disgusting little hack. W needed to talk to
the serial port from within Flash. We can't use Hernando Barragan's
socket server because our clients' IT people might complain about
having to work around it in their firewall. Frankly, I can't blame
them--who would want to compromise their own defenses, even given
additional functionality?
Anyway, I noticed the Shared Object, and thought Aha!
Finally, a way for me to talk to the computer without having to use
the network! The idea was that a client program would be watching
the file for changes, and would communicate with my Flash code via
this file. A shared medium usable by multiple parties is a means of
communication, so it should work. Well, I write up a quick and
dirty protocol, implement it on both sides, and test my code.
Everything can read the file, detect changes; it works nicely.
I go to the next level, which is figuring out when both
parties are willing to exchange information. This, too, works well,
and after some minor debugging tweaks, it's good to go.
Finally, I get things to the point where I can change the
contents of a variable in the shared object file, and the local
program will detect the change and send the contents of that
variable to the serial port. The trouble is that after I write to
the serial port, the Flash player apparently can't change the
contents of the shared object file. I've tried flush()ing the
shared object, I've tried deleting it and recreating it. I'm out of
ideas.
I realize that the above was enormously general, but would
anyone care to speculate on what might be going wrong?
Many thanks,
Bob Robertson

Answer 1

Success! It turns out that any modifications made to the SOL
file by an external program aren't reflected in the sharedObject
instance at all until the flash player restarts. If a new SOL file
is created while the flash player is open, and the flash player
then accesses a sharedObject with that name [i.e.
sharedObject.getLocal("newFile")] its values are detected as null.
I conclude that my earlier theory was correct: the flash
player, upon startup, looks in the appropriate directory for its
shared objects
once and loads their contents into its memory. Any changes
then made to the data in the shared object are not written until
that instance of the flash player closes, or unless the code calls
sharedObject.flush(). Therefore, a sharedObject is a one-way
communications channel: it can change the contents of the
publicly-accessible file at will, thereby allowing communications
to be sent to external programs. External programs, however, cannot
reply.
I did investigate cookies, and accessing them via javascript
and ExternalInterface or getURL("javascript: foo()"). It turns out
that browsers do the same thing with cookies that the flash player
does with shared objects: it writes changes to them, but doesn't
load them from a file to access their contents. Therefore, cookies
are also a one-way medium. They are, furthermore, less desirable
than shared objects, because a) they are placed in OS- and
browser-dependent locations, b) the file format is
browser-dependent.
My protocol spec is below, just on the offchance that someone
may find it useful:
Field List
toggle (Boolean)
nFromFlash (string, 1 char)
bufferFromFlash (string, “0”-suffix-padded to 32
chars)
To Send to Serial
Flash pads string to be sent with “0” to 32
bytes, writes string to field.
Use hex representation of numbers, for clarity:
“00” for 0, “10” for 16, etc, for
bufferFromFlash and nBytes
Flash sets value of nFromFlash (in hex)
Flash inverts value of toggle.
Flash flush()es the shared object to immediately write to
file.
Receiving from Flash
On start, record value of toggle in variable external to
parser storage.
On file change, compare current value of toggle with old
value of toggle. If different, send first nFromFlash characters of
bufferFromFlash to serial port.
The following URLs proved useful in writing a program that
understands .SOL files:
http://sourceforge.net/docman/display_doc.php?docid=27026&group_id=131628
http://sourceforge.net/docman/display_doc.php?docid=27130&group_id=131628
-Bob