4.6. Instance-to-Instance Communications

While an instance can request or close a connection to another instance at any time, the connection is typically made when the instance first starts and closed when the instance is about to be disposed. For example, a chat room instance may connect to a lobby instance in order to let the lobby know how many users are in the room and how active they are. This SSAS code example illustrates a chat room application connecting to a lobby on startup and disconnecting from the lobby on shutdown:

NetConnection.prototype.onStatus = function (info) {
  trace("NetConnection.onStatus> info.code: " + info.code);
  if (info.code == "NetConnection.Connect.Success") {
    // Initialize remote shared objects here.
  }
  else if (!this.isConnected) {
    // Handle close and other connection problems here.
  }
  if (info.code == "NetConnection.Call.Failed") {
    // Handle failed remote method calls here.
  }
};

application.onAppStart = function ( ) {
  trace(application.name + " is starting at " + new Date( ));
  lobby_nc = new NetConnection( );
  lobby_nc.connect("rtmp://localhost/chapter4/lobby", "Room", "secretPassword6");
};

application.onAppStop = function ( ) {
  if (lobby_nc.isConnected) {
    lobby_nc.close( );
  }
  trace(application.name + " is stopping at " + new Date( ));
};

The only difference between this server-side code and the client-side code you might find in a Flash movie is that a relative URI cannot be used (there must be a hostname) and HTTP tunneling is not available. The connecting instance is represented by the Client object passed into the receiving instance's onConnect( ) method. If a username and password system is being used, the connection can be accepted or rejected based on those credentials.

On the receiving end of the connection attempt, no special code is required to handle connection requests from other instances. However, sometimes it is useful to distinguish whether the connection request originated from a FlashCom application instance or a Flash movie. One way to differentiate is to check the ip property of the incoming client object. If the IP address is 127.0.0.1, then the connection is from the same server. However, if a poorly configured proxy server is running on the same host, all clients may appear to be from 127.0.0.1. Similarly, if connections are expected from another FlashCom Server, the IP address of the remote server can be checked for. There are other ways to distinguish between client types:

• Pass different information in the optional parameters of the connect( ) method.

• Check the client.agent property for a value such as "FlashCom/1.5.2".

• Check the client.referrer property for a value such as "rtmp://_defaultVHost_:1935/chapter4/room".

Regardless of the approach chosen, an additional authentication step should be used. The short code snippet that follows can be placed in an onConnect( ) method to handle instance connections before attempting to handle Flash movie connections.

The code assumes that a unique userName is provided by the connecting instance so that its client object can be kept in an object named roomList. The unique name could be the instance name of the room:

if (client.ip = "127.0.0.1" && client.agent.indexOf("FlashCom") == 0) {
  if (password == "room54780561Password") {
    roomList[userName] = client;
    return true;  // Accept the connection
  }
  else{
    trace("Invalid room connection attempt.");
    return false; // Reject the connection
  }
}

For variety, connections are accepted or rejected by returning true or false from within the onConnect( ) method in the preceding example.

Now that you have a better understanding of how to manage connections, let's examine some of the mechanics of locating code and configuration files.