Home arrow Flash arrow Page 2 - Communication and Security with the Flash Communication Server
FLASH

Communication and Security with the Flash Communication Server


In this article you will learn about using the Flash Communication Server with streaming audio, video, and ActionScript data; how to share data in real time; and much more. It is excerpted from chapter one of the book Programming Flash Communication Server, written by Brian Lesser, Giacomo Guilizzoni, Robert Reinhardt, Joey Lott, and Justin Watkins (Copyright © 2005 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media; ISBN: 0596005040).

Author Info:
By: O'Reilly Media
Rating: 5 stars5 stars5 stars5 stars5 stars / 6
December 14, 2006
TABLE OF CONTENTS:
  1. · Communication and Security with the Flash Communication Server
  2. · Sharing Data in Real Time
  3. · The Communication Classes
  4. · Firewalls and Security

print this article
SEARCH DEVARTICLES

TOOLS YOU CAN USE

advertisement
Communication and Security with the Flash Communication Server - Sharing Data in Real Time
(Page 2 of 4 )

Real-time applications often require data to be shared among or transmitted between multiple movies. The Shared Object class is familiar to many Flash programmers as a way to create a kind of supercookie; a local shared object (LSO) can store ActionScript data on the client between sessions. Flash communication applications can use remote shared objects (RSOs) to share information in real time between movies
running on different clients. If a movie updates a property of a remote shared object, the same property is updated in every other movie connected to it. When a shared object changes, each client is notified of the changes. Shared objects can be used to:

  • Notify all the movies connected to a video conference application of the name of every available live stream
  • Update the position of elements in a game
  • Hold the position, shape, and color information of each graphical element in a shared whiteboard
  • Hold the data for each form element in a shared form

In object-oriented programming (OOP), the data within all the objects in an application defines the current state of the application.

Shared objects provide a convenient mechanism to hold the state of a communication application distributed across multiple clients and servers.

Remote shared objects can be temporary or persistent. Temporary shared objects last only while they are being used. Persistent shared objects are saved on the server when they are not in use, allowing clients to pick up where they left off as soon as they reconnect to the server. Proxied shared objects are a mechanism for making shared objects available across multiple application instances; one application instance always owns the shared object but others can create a network connection to the master instance and create proxies (essentially an alias) of the shared object. That way, clients connected to any instance can connect to the same shared object. The feature is often important for creating large scale applications.

The code to work with shared objects on the client is a little different from that required on the server. Working with shared objects is also a little more complicated than working with streams or managing network connections. You need to do four basic things when working with shared objects:

  1. Get a remote shared object using SharedObject.getRemote( ).
  2. Customize the shared object so your program can respond to changes made to the shared object by each movie or by the server.
  3. Connect to the shared object.
  4. Once connected, update the shared object’s properties as necessary.

Chapter 8 provides complete coverage of using shared objects, but let’s have a quick look at what some client-side code looks like. On the client, the SharedObject. getRemote( ) method returns a remote shared object. However, the shared object usually needs to be set up with an onSync( ) method and then connected using a Net-Connection object before it can be used. Here we get a shared object namedusersto which each movie will connect. Then, an onSync( ) method is defined that, for demonstration purposes, displays information about changes made to the shared object as soon as they occur. Then the shared object is connected to the server:

  users_so = SharedObject.getRemote("users", nc.uri);
  users_so.onSync = function (infoList) {
    for (var i in infoList) {
     
var info = infoList[i];
     
switch (info.code) {
        case "change":
         
var id = info.name;
         
trace("User connected with id: " + id);
         
trace("and name: " + users_so.data[id]);
         
break;
       
case "delete":
         
var id = info.name;
         
trace("User disconnected with id: " + id);
         
break;
     
}
   
}
  };
  users_so.connect(nc);

The onSync( ) method is often the most interesting part of shared object coding. When the local copy of the shared object is synchronized with the server and whenever any slots (properties) in the shared object change, the onSync( ) method is invoked automatically. The onSync( ) method is passed an array of information objects. Each object contains information about the shared object or about what has happened to a slot (property) in the shared object. Chapter 8 describes shared objects and the onSync( ) method in detail. Each information object has acodeproperty, which describes what happened (“clear” if every slot is deleted, “change” if a slot is added or updated remotely, or “delete” if a slot is deleted). The name of the slot that has been updated or deleted is always found in the information object’snameproperty. To add or update data to a shared object slot within Flash, use thedataproperty of the shared object:

  users_so.data["guest_4"] = "brian";

Likewise, you can retrieve the value in a slot using thedataproperty:

  trace("The user's name is: " + users_so.data["guest_4"]);

Client and Application Objects

Whenever a client connects to an application instance on the server, a Client object is created on the server side to represent the remote client. The Client object can be used by server-side scripts to send and receive data messages to and from each individual remote Flash client. Every application instance also has a single application object that provides a convenient way to manage the instance’s life cycle. The applicationis a singleton instance of the server-side Application class.

Scripting Client objects and theapplication object is covered in Chapter 4. The Client andapplication objects, in concert with the ability to query web application servers, provide the core features needed to authenticate clients as they connect. Authentication is covered in detail in Chapter 18.


blog comments powered by Disqus
FLASH ARTICLES

- More Top Flash Game Tutorials
- Top Flash Game Tutorials
- Best Flash Photo Gallery Tutorials
- The Top Flash Tutorials for Menus
- 7 Great Flash Tutorials
- Adobe Creative Suite 5.5 Now Available
- Critical Flash Vulnerability Heats Up the Web
- More on Nonpersistent Client-Side Remote Sha...
- Nonpersistent Client-Side Remote Shared Obje...
- Using the Decorator Pattern for a Real Web S...
- Using Concrete Decorator Classes
- Delving More Deeply into the Decorator Patte...
- The Decorator Pattern in Action
- A Simple Decorator Pattern Example
- Decorator Pattern

Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 



© 2003-2012 by Developer Shed. All rights reserved. DS Cluster 4 - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials