Inside the Active Worlds Technology : The Uniserver Part 2
Written by
This article (part 2) discusses the universes role in maintaining world licences and directing users to world servers.

In the previous article we talked at some length about how citizenships authenticate to the universe server, in this article we discuss how the worlds system works and how users can connect to different worlds.

The universe server handles worlds in much the same way as it handles citizenships; it stores a single database containing the world information. This information consists of the world name, its hosting password and licensed size, capacity and features such as voice over IP and tourist access. This information is collectively known as the world licence.

Each world licence contains the following information:
- Name
- Password
- Maximum Users
- Land Size
- Owner Email
- Comments
- Created Timestamp
- Expiry Timestamp
- Last Started Time
- Last IP Address
- Display in World List
- Allow Voice Chat
- Allow Tourists
- Allow Plugins

The purpose of the universe server in relation to the worlds held within it is 3 fold; the first is to maintain the licences, the second is to authenticate hosting providers to ensure only the world owner can run the world and thirdly it maintains a list of the IP addresses of the servers with which the worlds are running on and forms the world list.

Universe and World Handshaking

When a hosting provider launches the hosting software (world server, covered in article 4) it connects to the universe server in much the same way as the client does, for example in the main universe this will take the form of establishing a connection to on port 6670.

The server will then attempt to register all of the worlds that it has been configured to host by sending the world name, instance and password. The universe server then checks its licence database for a matching world and password that is both enabled and yet to expire, if a matching licence is not found then the world server is informed of the error. Secondly a check is made to test if another host is already running the given world, likewise if this too is the case the world server is informed of the error.

Finally, if the password is correct and no other hosts are running the world then the universe server will register the world servers IP both in memory and write it as the last known IP of the world in the licence database. This process is repeated for every world that an individual world server is configured for.

This effectively results in the universe server building up a table of each running world and the hosting provider running it.

The universe server and each of its attached world servers remain in constant contact, with the individual world server being informed of any licence changes to worlds that it hosts, in this way worlds can be disabled or their dimensions / capacity changed instantly. Likewise, the world server can inform the universe server if the world is public or private, its rating, and if it is ceasing to host or shutting down – these elements are combined to form the ‘worlds list’ discussed later.

Clients and Worlds

The third purpose of the universe server is to allow browsers and SDK applications to locate and connect to individual worlds that are a part of it.

When this happens the calling application (for example the browser) begins by sending a request to the universe server for the IP and details of the requested world name. Before replying the universe will first check if there are limits placed upon access to the world by its ‘tourist accessible’ status. If a world is not tourist accessible but the requesting client is authenticated as a tourist then the request will be rejected.

Presuming that the client may be allowed to connect the universe server will then return the IP address that the world is currently running upon. The browser will then attempt to make a connection to this server.

The Worlds List

The final task of the universe server with regards to its child worlds is maintaining the worlds list. This list, accessible to both the client and SDK applications and can usually be viewed by selecting the worlds tab.

Like many features of the Activeworlds software the worlds list is handled by the client first requesting the list which will both return information on various worlds plus give a status indicator that tells if the list is incomplete in which case the client will again request the world list – this time it will receive the next part of the list. This is repeated until the whole list has been received.

For each successive request for the world list thereafter by the same client only the updates are sent, these requests are typically made between every 30 seconds and 1 minute.

The world licences and subsequently the worlds list itself feature the ability to hide individual worlds from appearing to normal users. This feature prevents the world from appearing on the list, but has no other effect upon the operation of the world – users may still teleport directly to the world by entering its name or clicking upon a teleport.


- The universe server is informed if a world has public or restricted access, however it does not maintain lists of enter permissions for each world. A user will only be rejected from a world based upon the worlds enter rights after the client has connected to the world server.

- In the event of a disconnection a new session is allocated to a client, this has the effect of resetting their copy of the worlds list and requires them to receive the entire list again.

In the next article we will discuss the contacts list, sessions, security hashes and universe user list.

Linking to this Article

BBCode: [url=]Inside the Active Worlds Technology : The Uniserver Part 2[/url]
Facebook is a privately held community resource website dedicated to Active Worlds.
Copyright (c) Mark Randall 2006 - 2024. All Rights Reserved.   ·   ProLibraries Live   ·   Twitter   ·   LinkedIn