Difference between revisions of "Server"

Revision as of 18:50, 29 September 2008

Overview

A server is usually a very powerful computer with several gigabytes of RAM and fast microprocessors.

In a UO context, each shard is a collection of servers running the software written by the game developers. With each Publish, additions or changes to the software are made and the code is copied to each shard which is then restarted with the new version code.

Conjecture and Ideas

Much of this is subjective and could likely be wrong and, even more likely, never officially acknowledged or dismissed in any capacity by EA/Mythic!

Some of these topics are closely held pieces of information, either due to competitive measures, security concerns or simply a policy of not divulging operational details.

Given that Ultima Online was launched in 1997, that Alpha and Beta testing began in 1996, that the game had been mentioned since at least 1995, and that there are continual public references and comments by the dev team on some of the more arcane and old pieces of code, it can be posited that a majority of the code and technologies used in developing UO was state of the art for 1995. Further, as that time period pre-dated much of today's free and powerful Open Source software, it can be posited much of UO was designed to run on commercial(and expensive) software.

In a nutshell, players install and run a piece of client software which then connects to a game server to interact with, namely play UO. Each shard, being a collection of servers, controls a specific region of the game world. Where the borders meet is known as a server line. Due to gains in microprocessor and overall hardware performance in over the decade since UO was first conceptualized, many if not all the subservers may actually now be virtualized instances running on a single piece of hardware. Similarly, many privately-run free shards are typically run on a single server, although with a much lower number of players connecting to play.

It is a loosely kept piece of knowledge that the shards originally ran on clusters of Sun Microsystems servers running Sun Solaris. At the time, Solaris was a popular choice for commercial applications due to it's stability and features, especially as Solaris is a type of UNIX. However, as the power and stability of Linux, a free, Open Source UNIX alternative to commercial UNIX distributions, improved and became more widely adopted, EA moved several of it's online games to the platform. By 2003, UO was running either on Red Hat Linux or a similar Linux distribution. By switching to Linux, EA was able to operate it's games on a much cheaper operating system as well as realize substantial hardware savings.

On the backend in the database area, which is where all game data such as characters, house locations, items, monster properties, etc. are stored, UO originally used Oracle Corporation's Oracle Enterprise Database product. Although it's uncertain what database UO currently runs on, due to the (relatively) low overheard of UO's resource requirements, an Open Source database solution is likely in use.

Lastly, given the series of qualifications periodically listed for vacant developer and server programmer jobs relating to UO, it can also be fairly stated that UO is written in C for the codebase with some game functions written out to be called from scripts. This is partially why some changes to the game world can be done in "real time" whereas others may require the shard to be restarted after new code is pushed out. It is unknown if UO began with Borland C, GNU C or which is in use today, although highly unlikely Borland C.

Going a bit futher out on a limb, UO also began displaying significantly shorter maintenance periods in 2000 by a factor of 5. This is likely attributed to the ability to take storage system snapshots of the database, which also began in some commercial storage products around the same time period. In brief, the databases are quiesed to a stable state and then the snapshot is taken. The snapshot is actually a series of logical pointers to individual file states flagged with a timestamp and not a completely seperate copy of the original data. The databases are then brought back to an operational status and the incremental changes from the snapshots are recorded. Meanwhile, a backup is made from the snapshotted files. In this way, daily backups, the primary purpose of the maintenance period, can be made with minimal downtime to the players.