Clustering

I. General SWGEmu-ORB

a. The Acronym

ORB is acutally a shorter acronym for CORBA. Which stands for "Common Object Request Broker Architecture". SWGEmu uses CORBA as a base and extended ORB to fit our needs.

b. Overview

Due to the complexity of CORBA, it is impossible to give even a general overview without skimping on details that make CORBA what it is. If you would like to know more, please see this wikipedia article on it. Our implementation and how SWGEmu extended CORBA into ORB is covered in Section III.

c. ORB in SWGEmu

ORB allows SWGEmu servers to fully utilize server resources by effectively distributing world objects across all machines, reguardless of the actual location of the object. This creates true load balencing and increased performance benefits per machine. World Objects that are not servicing the player do not have to be created/handled by the servers, we can simply delete and forget - just create them when they are needed. ORB is easy to implement in new world objects, and requires almost no extra maintanance. The game is a seamless experience to the user and removes the burden of the server operator to worry about which machine is handling what piece of terrain. The machines in the clustering pool work together almost in parrallel to seamlessly service the SWG world.

II. SOE Clustering v.s. SWGEmu-ORB Clustering

a. Estimated SOE Model

The specifics of how SOE distributes load across their servers has never been a definately determined by the public, but it is generally accepted that a player is physically handed off to another server when a boundary is crossed. Weather this is true or not, there is no way of really knowing besides hints from previous patch notes ([1] [2] [3] [4] Ctrl+F "bound"). This diagram gives a rough idea of how we thought SOE distributed SWG back in 2005, and our assumption based on that model still holds true today. Ex. 1-2. 1 Being the planet, 2 being the server #.

We know for a fact that the client only initiates one physical connection to an SOE "Connection Server" and does not break it until the client terminates. In this model, the connection server act's as a proxy to the outside world. It sends the data to the appropriate planet server which then process' information and queue's backend work (database etc.). This switching mechanism requires a great deal of managing effort behind the scenes and would probably consist of an reliable internal software level network protocol to facilitate player switching at a reasonable response time. Other popular MMORPG's such as FFXI have been known to break the connection to one server, and initiate a new one when needed. Due to the fact that SWG maintains a single UDP connection to SOE and the vast size of terrain, it would be inefficient to initiate a new connection every time a server transfer were to take place. Based on the clues picked up from Live SWG bug reports and patch notes, it is hard for us to imagine that SOE distirbutes the load otherwise - especially at a low level like ORB due to the boundary issues.

b. SOE-Clustering Advantages/Disadvantages
Advantages:

1. Machine failure is acceptable if player states were saved on the connection server.

2. Minimal downtime on specific areas with bugs. If a specific area had a damaging exploit avaliable to players, the area could be taken down without requiring an entire planet to be shutdown.

Disadvantages:

1. Heavy dependance on the connection server - bottleneck. Connection Servers are never switched after the login server has specified which connection server to use.

2. Hard to maintain, pressures developers to put less amount of content on boundaries.

3. Would not be classified as true "load-balencing". This does break the vast terrain into smaller and more manageable chunks, but it is unreasonable to expect all areas of the terrain are going to be populated. Major cities/battlegrounds would be densely populated thus putting more strain on some machines more than others, effectively wasting processing power. Breaking densely populated areas into more servers on this model would increase the number of boundary errors seen in the past.

4. Wasted processing power on areas of constant low population.

5. Requires persistant maintanance on areas without players. NPC's and other entities could not be _effectively_ populated on the fly. Servers would need to keep constant track of world entities even though they aren't being utilized by real life players. Again, a waste of resources without benefitting customers.

c. Is it worth it?

Short answer: No. From cost, performance, and long term maintainability perspectives, the ORB architecture was the clear winner for SWG clustering.

III. Implementation

a.