If you haven't been following the commit messages to the ogoglio repository, we've mad a few changes and I thought it might be good to explain why on the blog. Lately, we've added support for running the database/media service, the webapp service, and the "sim" service on different machines. The three members of this "triumvirate" need to pointed at each other by configuring some URLs in server.xml. (For people doing development and running the whole setup on one machine this should no ill effects--you just point everybody at 127.0.0.1 and it'll be fine. We do it all the time.)
The first two members of the triumvirate, database and webapp, are pretty straightforward. They work in exactly the way anyone would expect of a two-tier, RESTful service that is backed by MySQL. Web requests come in to the REST API of the webapp server and it may need to fetch data from the MySQL server to handle the request before replying. Adding just a bit of a twist, there is a different web application, the media service, that runs on the same host as the mysql server. This service is basically just a way to store big blobs of unstructured data in a bag. This is used for holding model data (which can easily get to be several hundred K), textures, and other bits that you don't want in the mysql store. The properties of these files are stored in mysql and can be queried, but the actual data itself resides in the humble media store and is accessed by name.
More unusual for people familiar with web services is the third triumvirate member, the sim service. This is also a web service but it is used only for simulating spaces. When a space is created and entered by a user, a "sim" (simulator) is fired up on the sim server via the sim web api. This simulator encodes the system's knowlege about the state of the space including all objects in the space and all users. When a user "moves around" in the space, the user's client sends the movement info (a spline path) to the server. The server is responsible for informing other clients about the motion of the client that moved. Further, the sim itself does calculations about things like collision detection and is responsible for running scripts that need to be activated. The sim can be quite computationally/IO expensive due to the amount of networking and geometry computing it needs to do--thus we allow it now to split onto a separate machine.
There are only three interesting numbers to a computer scientist, zero, one, and infinity. When we enabled ogoglio's sim server to move to a separate machine, we also allowed you to run many of them. So, if you have many spaces with many users you can spread the compute load around. At the current time, though, the front-end code isn't smart enough to choose a sim based on it's load or anything like that, it simply assigns a space to a randomly chosen (but known to be up) sim server. Further, when all the users have left a space and it is idle for a period of time, the space is "shutdown" and it state saved for later, freeing up the sim server to compute on a space that is in use.
The sim server, while not directly visible to the clients, is the heart and soul of an ogoglio system. It does the "heavy lifting" of the computation of the virtual world while web front end and mysql server handle the more traditional web parts of the system.
Comments