Ryerson Flash Communication Development Server

Lobby and Chat Rooms Test Application

Introduction

This test application extends some of the basic ideas presented in Lobby and Rooms Test Applications to a working test application that includes:

• a simple ticketing system that helps control clients moving from lobby to room to lobby instances;
• a very simple chat application;

This is only a test application. Please see Macromedia's Flash Communication Components and Mike Chambers and Greg Burch's chat for more fully developed chat systems.

The basic test scenario

To keep things simple this test application doesn't do too much:

• Only five application instances can be created named: lobby, room_1, room_2, room_3, room_4- no other instances will accept connections from clients.
• Clients connected to the lobby can see each message when it is posted in each room and some information such as name, ip, and referrer for each client in the rooms;
• Clients only connect to one instance of the application at a time - this is facilitated by the ticketing system. To connect to a room the client must have first aquired a unique user name and then a timestamped ticket from the lobby application. To return to the lobby the client gets a new ticket from the room.
• The chat system sends each message to the server via a remote method call before it is distributed to the clients. Messages are tagged on the server with the sender's name. Messages can be broadcast to all clients in the room via a shared object send method or sent to only a subset of users.

The application makes use of two shared objects in the lobby instance of the application. The room instances connect to the lobby and then get these two shared objects. One object, the room list, is used to provide public information about who is in each room. The user list shared object contains confidential information such as ticket values and the time window the ticket is valid in.

Using tickets to maintain client identity

In this small test application anonymous users select a user name before connecting to the lobby. If the user name is not being used by anyone else it becomes their unique name while visiting the lobby and the rooms until they leave. If it is being used by someone else the user has to try to connect with another name. To avoid complications such as there being two users with the same name, one in the lobby and another in a room, user names must travel with the user's client. In addition the system should force users to connect to the lobby first where they aquire their user name. Doing this might look simple at first. All that has to happen is that the client needs to remember the user name and use it when it connects to a room or back to the lobby. Unfortunately, this simple approach will not stop anyone who wants to hack a Flash movie from grabbing someone else's user name and masquerading as that person. One way to insure that the client that disconnects from the lobby is the same client that is attempting to connect to a room is to issue a unique ticket to the client. The ticket acts something like a transfer ticket in a public tansit system that people use to change buses. The client must present the ticket when it is changing connections. The ticket is only good for a limited time and can only be used once. Here is the sequence of events that would be used to allow a client to disconnect from the lobby and then connect to a room:

1. The client requests a ticket from the lobby using a remote method call.
2. The lobby application generates a ticket using a timestamp and random number.
3. The lobby application stores the ticket in the user list shared object so the room instances can check it there.
4. The client receives the ticket from the lobby and disconnects.
5. The client connects to the room and passes it the user name and ticket.
6. The room application looks up the ticket and user name in the lobby's user list shared object.
7. If the ticket is identical and has not expired the client's connection is accepted. Otherwise it is rejected.

A hacked client that attempts to masquerade as someone else will not have the ticket and their connection attempt will be rejected.

The first attempt

In the first attempt to make this work a User class was defined. Each server-side client object is assigned a user object that contains information about the user including a ticket if they have one. This is setup whenever a client connects to the lobby. The simplified code snippet below shows this:

client.writeAccess = "/../../../"; // Don't want this client writing anything!
client.readAccess = "/public";     // Can read the roomList_so but not the user list.
client.user = new User(userName, client.ip, 0, client.referrer);

userList_so.setProperty(userName, client.user);
application.acceptConnection(client);
client.call('lobbyWelcome', null, client.user);

All the User objects are also stored in the lobby's userList_so shared object. The room instances connect to the lobby instance and proxy the userList_so shared object. When a client (the Flash movie) is ready to go to a room it asks for a ticket using a remote method call:

   lobby_nc.call('user.getTicket', this.ticketHandler);

On the server, the getTicket method of the User object is called and the return value is passed back to the Flash movie's ticketHander object's onResult method. The ticket handler class is relatively simple:

function TicketHandlerClass(requestor, current_nc, destination_nc){
   this.requestor = requestor;
   this.current_nc = current_nc;
   this.destination_nc = destination_nc;
}


TicketHandlerClass.prototype.onResult = function(result){
   this.requestor.acceptTicket(result, this.current_nc, this.destination_nc);
}

In this case the acceptTicket method of another object in the Flash movie is called. It disconnects from the lobby and tries to connect to the room. It passes the userName and ticket to the room instance it is trying to connect to. Here is the source:

ApplicationManager.prototype.acceptTicket = function(ticket, current_nc, destination_nc){
   this.ticketHandler = null;
   if (ticket){
      this.user.ticket = ticket;
      current_nc.close();
      destination_nc.setAddress('rtmp:/' + this.roomName);
      destination_nc.connect(this.user.userName, this.user.ticket);
   }
   else{
      this.user.ticket = 0;
   }
}

If you try the application using the link below you will see that most of the time this simple "transfer ticket" system works. But sometimes it fails. It does this because two things are happening simultaneously on two different computers. On the server, the user's ticket is stored in the user list shared object. But it takes time for the change in the shared object to be replicated to all the other instances. This is illustrated in the simplified interaction diagram below that shows the userList_so.setProperty statement being used to set the ticket in the lobby:

After the ticket is set in the lobby, the copy of the userList_so object in the room instance is updated by the server at the same time that the client is disconnecting from the lobby. So, it takes a little time before the room instance's copy of the shared object is updated. At the same time this is happening the client is disconnecting from one instance and trying to connect to another one. If the ticket has not been updated yet in the copy of the user list where the client is trying to connect to, the client's ticket will not appear to be valid and the connection will be rejected. Here is an illustration of how this can happen:

There are two competing processes at work. The time it takes for the client to disconnect and attempt to reconnect to the room and the time it takes for the userList_so to be updated in the room instance after being set in the lobby instance. In the illustration above it took longer to update the user list so the connection attempt by the client will fail. Some solutions to this problem are described below. Here is the first attempt that demonstrates this problem:

Use the link below to create a number of pop up windows to try this out. Try entering a name into the login screen and explore the lobby and simple chat rooms. At some point when you are moving from lobby to room or back you may find you simply lose your connection to the system. Further down on this page you will find the solution to this problem.

Open the swf file in a browser window.

Here are the source files for the client - many of these are quite short:

• ChatClient.fla - the Flash file itself does not contain any code.
• BroadcastConverter.as - makes an object listenable.
• ChatClient.as - contains the main application level source for the Flash movie.
• ChatForm.as - the code for the ChatForm movie clip.
• HashCodeManager.as - provides unique numberic identifiers for any object that needs one.
• LobbyForm.as - the code for the LobbyForm movie clip.
• LoginForm.as - the code for the LoginForm movie clip.
• NetConnector.as - a simple subclass of NetConnection.
• RoomClientListDialog.as - code for the movie clip.
• RoomPreview.as - code for the movie clip.
• TicketHandlerClass.as - a class that facilitates callbacks.

Here are the server-side script files:

• main.asc - loads the lobby, room, or rejectConnection file depending on the instance name.
• lobby.asc - code for handling connections to the lobby.
• room.asc - code for handling connections to any of the rooms.
• rejectConnections.asc - does what it says if the wrong instance name is used.
• User.asc - a class so that each client object can have a user object.
• ChatClass.asc - provides very very basic chat services.
• Harvester.asc - an object that deletes unused user entries.
• HashCodeManager.asc - provides unique ids for objects.

The corrected application

There are a number of ways to fix the problem described earlier. All of them have one thing in common. The client must wait until the ticket becomes available to the destination intance of the application before trying to change connections. The following briefly outlines some ways to do this:

• Don't use a shared object to store user information. Use a database to store user information including ticket values. Changing instance connections can be done this way:
  1. The client requests a ticket from the instance it is connected to. For example by calling a server-side function named getTicket.
  2. The instance creates a ticket and uses remoting to store it in the database. A callback function is created that is called when the database transaction is completed.
  3. The server-side getTicket function returns without the ticket and the client does nothing.
  4. When the database transaction is complete the callback function is called.
  5. The callback function calls a client method and passes it the ticket.
  6. The client disconnects from one instance and presents the ticket to another one.
  7. The instance checks the ticket value in the database and accepts the client.
• Instead of having an instance directly update the user list shared object, it can ask the destination instance to update it using a remote method call. When the call returns the other instance will have updated the shared object and be ready for the client. Here is a step-by-step description of how this works:
1. The client requests a ticket from the instance it is connected to.
2. The instance creates a ticket value and passes it to the destination instance via a remote method call.
3. When the ticket request returns the client does nothing.
4. When the remote method call to the other instance returns the instance the client is connected to calls a method on the client and passes it the ticket.
5. The client disconnects and attempts to connect to the other instance.
• Write an onSync handler for each instance. When it sees a ticket value has changed, and that it is the destination for the user, it sends a message to the instance the user is connected to. That instance then tells the Flash movie it is safe to disconnect and try to connect elsewhere.

Any of these will work but the second one is illustrated here because it is easy to code and doesn't require remoting. A production system would likely use a database instead of a shared object for this function. Here is a simplified interaction diagram that shows that this approach will always work as the client always waits until the shared object is updated on the destination instance.

In this example the client does nothing after the getTicket remote method call to the lobby. Instead a sequence of remote method calls lead the client being told to change connections after the user list shared object has been updated in the destination instance.

Open the swf file in a browser window.

Here are the source files for the client - many of these are quite short:

• ChatClient.fla - the Flash file itself does not contain any code.
• BroadcastConverter.as - makes an object listenable.
• ChatClient.as - contains the main application level source for the Flash movie.
• ChatForm.as - the code for the ChatForm movie clip.
• HashCodeManager.as - provides unique numberic identifiers for any object that needs one.
• LobbyForm.as - the code for the LobbyForm movie clip.
• LoginForm.as - the code for the LoginForm movie clip.
• NetConnector.as - a simple subclass of NetConnection.
• RoomClientListDialog.as - code for the movie clip.
• RoomPreview.as - code for the movie clip.
• TicketHandlerClass.as - a class that facilitates callbacks.

Here are the server-side script files:

• main.asc - loads the lobby, room, or rejectConnection file depending on the instance name.
• lobby.asc - code for handling connections to the lobby.
• room.asc - code for handling connections to any of the rooms.
• rejectConnections.asc - does what it says if the wrong instance name is used.
• ConnectionChanger.asc - an object that is called when a ticket is changed on a destination instance.
• User.asc - a class so that each client object can have a user object.
• ChatClass.asc - provides very very basic chat services.
• Harvester.asc - an object that deletes unused user entries.
• HashCodeManager.asc - provides unique ids for objects.

This document was written by Brian Lesser and last updated: