Server architecture

This wiki is mainly focused on the viewer, since that is the portion of the system that is open source. However, because the viewer interacts with the Second Life servers in somewhat complicated ways, it is helpful to have an understanding of what components do what on the server side.

Much of what you'll need to understand is actually covered in the protocol documentation. In particular, take a look at Authentication Flow, which outlines the process by which the viewer establishes connections with a number of components.

(obsolete) if you want to see what the architecture may look like in the future, or if you would like to help shape it, visit the Architecture Working Group.

Components

Login server

CGI script running on login.agni.lindenlab.com. Handles verification of user name and password. Determines the login region based on home vs. last location vs. URL specified location. Finds the simulator process running that region and verifies user is allowed to connect there. Alerts the simulator to expect a connection. Informs the viewer of where to connect.

Spaceserver

Handles routing of messages based on grid x,y locations. Simulator talks to Space Server to *register* and also find who the neighbors are.

Dataserver

Handles connections to the central database, log database, inventory database(s) and search database(s). Performs queries on behalf of the simulator process.

Simulator

The primary SL server process. Each simulator process simulates one 256x256 meter region.

There are about 26,000 regions in total in 2026. Each one is hosted on an AWS EC2 instance within an AWS ECS container.

It handles storing object state, land parcel state, and terrain height-map state. It performs visibility calculations on objects and land and transmits the data to the viewer. It transmits texture data in a prioritized queue. Physics simulation is handled with the Havok physics library. Chat and instant messages are processed here. The viewer is handed off from one simulator to another as it moves between regions.

Running at full tilt, a simulator will run at 45 frames/sec. If it can't keep up, it will attempt time dilation without reducing frame rate. More details on work performed during a frame are in Simulator Main Loop.

Simulators communicate with one another using a circuit via UDP. A "circuit" is a UDP network connection. Circuits are maintained between adjacent simulators.

Simulator vs. Viewer

It helps to understand the division of labor between the simulator and the viewer, since the split in Second Life is very different than most other virtual environments:

• Simulator's job:
  • Runs physics engine
  • Collision detection
  • keeps track of where everything is
  • Sends locations of stuff to viewer
  • Sends updates to viewers only when needed (only when collision occurs or other changes in direction, velocity etc.)
• Viewer's job:
  • Handle locations of objects
  • Gets velocities and other physics information, and does simple physics to keep track of what is moving where
  • No collision detection

Other servers

• Central Backbone
• Agent Database
  • Agent DB keeps track of metadata<->item id (UUID) mapping
• Central DB (CDB)
  • a list of who owns what, used for billing, etc
• Find DB (replica of Central DB used for search)
• Map server - renders overall map with OpenGL
• RPC server
  • API for developers to manupulate Second Life without using the viewer
  • Translates XMLRPC server into in-world requests
  • Communicates with space server and CDB
• Region Conductor
  • Looks for regions that should be running, but are down
  • Start those regions on a sim host that has room for it
  • Grid Restart Modes
    • Startup Mode: Regions are stuck on the current sim host
    • Normal Mode: Regions are sent to a random sim host