The Server


Unity 2 Multiuser Server (U2MS) is commonly called a Socket Server. This is an oversimplification. Managing Socket connections is a relatively small part of what U2MS does. More correctly, U2MS is a Container for providing services to Remote Connections. This includes managing server resources (eg. Clients, Rooms, Namespaces), events, security, administration and persistence. As well U2MS is bundled with a Room called UPCRoom based on a higher layer protocol called UPC which provides additional services.

How the Server Works

Remote Clients, typically written in Flash (although the Server works equally well with other Socket-able languages such as Java, C++ and PERL), make TCP Socket connections to the Server. Clients send and receive messages through Rooms. Commonly the Clients will join Rooms they are interested in but they may also, depending on configurable options, also send and receive Messages from Rooms they are not in.

Clients can broadcast messages to other Clients individually, to all Clients in a Room, to all Clients in a Namespace, or all Clients on the Server. Through Rooms, Customized Services and other deployable support Objects U2MS can also create and broadcast Messages to Clients.


A Client is a connection to the Server. Clients communicate with Rooms and typically join Rooms from which they will send and receive Messages.

A Client can have attributes. The attribute can be Server or Room scope. A Server scope attribute is unique for the Client across all Rooms. A Room scope attribute is unique per Room. For example, a Client may have a different Room scope attribute "currentscore" for several Rooms while having a Server scope attribute "name" which is unique across all Rooms.

Client attributes can be shared. Updating of shared attributes occurs on a "need to know" basis. So Clients are only notified of the shared attributes of other Clients if they are in at least one common Room. Examples:

Eg. 1: Two Clients in separate Rooms will not get updates when their shared attributes change.
Eg. 2: Clients within a Room will be updated when their shared attributes change.
Eg. 3: Clients in a Room will be notified of the shared attribtues of any Clients that join that Room.

Client Attributes can be made persistent over multiple Client connections if used with an AttributePersistent Object.


A Room is a hub of communication. Primarily a Room receives and sends Messages to Clients although it can do much more. Rooms also act as a means of grouping Clients with an interest in a similar service though Clients within the same Room need not necessarily know about each other.

A Room can have attributes. Attributes allow you to customize a type of Room among many instances. Attributes can also be shared. Clients are automatically notified of shared attributes when they join the Room or when the attribute changes. Room Attributes can also be made persistent.


A Namespace is a collection of similar Rooms. For example you might create a Namespace games.starbattles to hold all of your Starbattle Game Rooms. Using the API available to Namespaces you can perform actions on all of the Rooms within your Namespace such as a broadcast or getting a Client count. Namespaces are organized in a hierachy. So games.starbattles is a sub-Namespace of the Namesepace games. Most actions on a Namespace can occur either on the Namespace specified only or recusively. So getting a recursive Client count on the games Namespace would give you a single total count of how many clients are in games.starbattles, games.seabattles,, etc.

If you do not specify a Namespace when creating a Room the default Namespace 'udefault' is used.

Namespaces can also be "observed" by Clients. This means Clients are automatically notified when a Room is created or killed within the Namespace.

Note that the "udefault" namespace is automatically observed, so adding a room to it will automatically generate a NamespaceListener.onAddRoom() event.