Section 8.8. Avoiding Collisions

8.8. Avoiding Collisions

When a movie attempts to update slots in a shared object, the server locks the properties of the server-side copy of the shared object the movie is attempting to update. Any other movies that attempt to update a slot while it is locked will receive an information object with a code value of "reject" for each locked slot in the list passed into the shared object's onSync( ) method. So, if multiple movies attempt to update the same property of a shared object at nearly identical times, only one movie will succeed. The other movies will receive notice that their change requests were rejected. In some applications, rejected updates are an inevitable and necessary feature of the application. In others, steps should be taken to avoid slot update collisions. For example, it is interesting to see several people try to control the shared ball at the same time. The ball may move erratically around the Stage, but no harm is done. However, multiple users sharing a whiteboard application will prefer that each person has complete control of a drawing tool and can complete part of a drawing without interference from other users.

Here are a number of ways to avoid shared object slot update collisions:


Use separate shared objects.

For example, if each user is represented by an avatar that follows the movement of his mouse, separate shared objects can maintain the coordinates and color of each user 's cursor. Each shared object should have a unique name based on the username or an ID number.


Use a naming convention for slots to keep them separate.

For example, if each user has a unique user ID (a name or number will do), the ID can be used as a prefix for every property name. An avatar system could use three properties in the same shared object for each avatar, separated from the ID with a common character such as an underscore . For example:

blesser_x: 23

blesser_y: 76

blesser_color: #ff0000

peldi_x: 301

peldi_y: 216

peldi_color: #00ffff


Use a cooperative system mediated by the server.

When a slot must be updated by more than one movie, control of the slot can be cooperatively assigned to one movie at a time. Often remote method calls (see Chapter 9) are used to request access to a shared object or shared object slot because they are reliably queued by the server. The server can pass control to each movie in turn or use some other method to allocate control.


Do not update shared objects in the client.

A common approach when updates may conflict or where no updates can be dropped is to send data to the server using NetConnection.call( ) , which is described in Chapter 9. The server processes the updates it receives from each client and writes whatever data is necessary into the shared object.



Programming Flash Communication Server
Programming Flash Communication Server
ISBN: 0596005040
EAN: 2147483647
Year: 2003
Pages: 203

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net