Getting Started > Deploying applications and application instances > Using application instances

Using application instances

Applications are run by creating application instances. When a client connects to an application, the client is actually connected to an application instance. For example, a client connects to an application named chat_app:

nc.connect("rtmp://myDomain.com/chat_app");

In this example, the client is actually connected to the default instance of the application, named _defInst_, because no instance was specified.

Clients can also connect to specific application instances defined by the instanceName value in the NetConnection.connect command.

nc.connect("rtmp://myDomain.com/chat_app/instance1");

In this example, the client is connected to the application instance named instance1.

You might want to use application instances for specific purposes. For example, you may want to give different groups of people access to the same application without having the groups interact with each other, such as in a chat application with "rooms" for different topics. To do this, you can have multiple instances of the chat application at the same time, as shown below.

my_nc.connect("rtmp://myServer.myDomain.com/chatApp/room_01")
my_nc.connect("rtmp://myServer.myDomain.com/chatApp/room_02")

Each application instance is uniquely named. Unlike the parent application, an instance does not need its own directory to be defined on the server. However, application resources, such as streams and shared objects, are independent for each instance and are stored in their own directories under the streams and sharedObjects storage directories configured for the application.

Another reason to use application instances is to avoid collision of recorded streams or shared objects that are created by the application. In the above example, for instance, any streams or shared objects created by room_01 are distinct from those created by room_02, and vice versa, even though both instances are running the same application, chat_App.

For example, although the support application in the following code creates two shared objects named CustomerInfo, each instance of the support application has access only to its own CustomerInfo object. Also, the data in CustomerInfo used by session1 is different from the data in CustomerInfo used by session2.

// One instance of application "support"
first_nc = new NetConnection();
first_nc.connect("myserver.mydomain.com/support/session1");
first_so = SharedObject.getRemote("CustomerInfo", first_nc.URI, false);
first_so.connect(first_nc.URI);

// Another instance of application "support"
second_nc = new NetConnection();
second_nc.connect("myserver.mydomain.com/support/session2");
second_so = SharedObject.getRemote("CustomerInfo", second_nc.URI, false);
second_so.connect(second_nc.URI);

Many of the samples in this manual use the instance name room_01. However, you can use any string for an instance name that makes sense in your application. For an example of dynamically creating an instance name, see the tutorial_textchat.fla sample file in the /tutorial_textchat directory.

You can configure several settings related to application instances. In the Application.xml file, you can configure the maximum idle time before an instance is unloaded by the server. In the Vhost.xml file, you can configure the number of clients that can connect to the virtual host hosting an application and the number of instances that can be loaded by the virtual host.

For more information on using instance names, see the NetStream.publish entry in the Client-Side Communication ActionScript Dictionary. For information on making remote shared objects available to multiple applications, see the SharedObject.getRemote entry in the Client-Side Communication ActionScript Dictionary.