Architecture of basic app with no components

Great, thanks.

1. Data gets lost. So, the solution is to not let multiple users write to the same property. So what would I do in the case that I *want* users to write to the same property? In the drawing app, I can't think of a legitimate reason, as I can always merge multiple users drawing data on the client side, but what about an example such as game where users kick around a ball. There would be only one ball with an x,y, and all users would somehow have to modify the ball x,y.

2. Too much data. So, my sturucture was like this:
SO -> drawingN:Array - pointN:Array
In the suggested alternative, the drawing data is not divided, so all drawing data for all drawings would be in the same Array... I guess that's not really a problem, I'd just add another property to define what drawing the point belongs to.

BTW, I keep reading about "slots". As far as I can tell from context and description, it seems like a "slot" is just an Array. What is the difference? Is a "slot" just the term for a SO property, which is really functionally like an Array?

You have two problems:

1. Data gets lost.
2. Two much data is being transferred.

The lost data is due to the fact that all clients are rewriting the same data at the same time. One solution to this is to hav a unique id for each client and let everyone write to his own property on the so:
clientId = 1;
...
so[clientId + "_drawing"] = [...

The second problem is due to the fact that you are rewriting an entire array of objects each and everytime a point is updated. If you separate each instruction into a unique property on the SO, that's the only data that will be transferred instead of the whole chunk:
clientId = 1;
drawingInstructionCounter=0;
...
so[clientId + "_" + (drawingInstructionCounter++) + "_drawing"] = {action:'lineTo', x:25, y:45, color:0xff0000};

This has the added benefit of you not having to keep track of what's allready updated. The only data in the onSync event is new data.

To finally streamline it some more, try to keep the transferred data to a minimum at all times:

clientId = 1;
drawingInstructionCounter=0;
...
so[clientId + "_" + (drawingInstructionCounter++) + "_d"] = {a:'lt', x:25, y:45, c:0xff0000};

/Johan
Man Machine

Thanks again, both, I've put together a drawing app with sharred cursors and what-not, using no components. I think I just fell in love with FMS.

However, the lag on the drawing part is something awful. We are using a low budget account from Influxis--I don't have the specs but I want to say something like 10 connections and low bandwidth, so I'm sure that plays a role. However, the cursors seem to broadcast and update fine, it's just the drawing.

How I'm doing the drawing is using a single SO, "drawings_so", which contains named drawings, like "myDrawing","anotherSketch", etc. Those are Arrays which contain a brutally long list of drawing point data, like this:
[
{action:'lineTo', x:25, y:45, color:0xff0000},
{action:'lineTo', x:45, y:15, color:0xff0000},
{action:'moveTo', x:255, y:455, color:0xff0000},
etc.
]

A new point object is generated onMouseMove(when the user is drawing), so the data gets big very fast. I'm using a simple onSync event, and it gives me the drawing object, ex "myDrawing" or "anotherSketch" after they change, which conains the entire drawing in stored points like above. I'm doing some simple tracking in the client so that it doesn't have to redraw the entire thing, only the new stuff, but the lag between SO onSync updates is quite large. I've also noticed that if more than one user is writing to the same drawing(ex. "myDrawing" in drawings_so), data gets lost and out of sync.

Any comments on this architecture? Any tips on speeding things up or doing things smarter? Right now, for the sake of testing, I'm not doing anything server-side, but would move that direction.

It seems as though writing/reading from a SharedObject is not the most efficient way when doing such constant updates between multiple clients, can NetStream replace that functionality in this case? The problem seems to be in the the loadtime of the SharedObject, as if the clients have to completely reload the remote SO when its updated.

Thanks in advance!

NetConnection
NetStream
SharedObject
Video

That's about all you need.

SharedObjects propagate their changes to all clients who have connected to them.

To create a chat, you can either set up a SharedObject as a chat room and have all clients read and write the messages from/to the SO or you can write some server side code (there it is!) that recieves a NetStream (which you can write allmost like a normal Stream) and broadcast it to all recipients.

/Johan
http://www.man-machine.se

For starters, you might want to pick up a copy of "Programming Flash Communication Server" (O'Reilly). It's a very comprehensive guide, and all of the info in there is applicable to FMS. It will teach you everything you need to know to get away from the prefab communication components (It will also teach you how to use the component framework to build your own components, but you don't have to do that if you don't want to)

When a shared object is updated (either on the client side or the server side), the update is automatically broadcast to all of the clients... assuming the sharedObject hasn't been locked (you can programatically lock/unlock so's). The sharedObject class has an onStatus method, which is invoked every time there is a change in a property of the shared object. Both the client and the server can have onStatus handlers for any shared object.

The role of SSAS is pretty far reaching. Quite honestly, I prefer to have the server handle writing/updating so's rather than allowing it to happen on the client side. I could go on all day explaining why, but the short answer to it is having a single point of control over the shared data. If only the server writes SO properties, you can more easily control conflicts and collisions.

The chat example is a little much to type here. I'll see if I can find a link to an existing tutorial.