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.
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, games.cards.poker, 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.