Running the dev preview

Disclaimer

This page documents how to actually run The Sirikata Dev Preview (codename Meru) servers and clients once you've compiled the source. Beyond some simple options that won't change, everything is controlled by the options mechanism. So if you can't find something here (or it doesn't seem to match up with your experience) your next stop should be Options.hpp and Options.cpp in the source tree.

Notes for All Scenarios

In all cases you need to start the client and server from the Meru/data/bin/ directory. This is required so we can find all the necessary libraries and resources.

Also, some commands in here are quite long because they require specifying a lot of parameters. You should be able to set up configuration files to save you some typing. Just run dev preview specifying the config file on the command line and it should pull in all the options correctly, e.g.:

 ../../src/meru --config=server1.cfg

Single Server, Multiple Clients

This is the simplest mode to get running. All the options default to settings appropriate for this scenario. To run the server, simply run

 ../../src/meru --mode=server

This starts the server up with all the default subsystems (see descriptions below).

Multiple Servers, Multiple Clients

In this mode, the method for starting clients remains exactly the same, simply adjust the connection parameters for each one to connect to different servers. Note that you can do this from the command line, e.g.:

 ../../src/meru --username=testplayer --password=testplayer --server=mytestserver --port=mytestport1

Server Options

In order to get a functional distributed server system working you need to specify distributed implementations of all the server subsystems. Below are listed the subsystems by the option name (by which you specify them on the command line) followed by the implementations. For many, the current "distributed" implementation is in fact one that works with multiple servers but is centralized on yet another server.

• Account Manager (--accounts=) - sqlite, smalltable
• Proximity Manager (--proximity=) - simple, bullet, central
• Object Storage (--object-store=) - sqlite, smalltable
• Message Router (--message-router=) - local, smalltable
• Reference Registry (--reference-registry=) - sqlite, smalltable
• Object Connection Manager (--object-connections=) - simple, smalltable

You will also need to set separate listening ports for each server.

Centralized Utilities

Many of the current "distributed" subsystems require a centralized controller. Currently this refers to all the smalltable implementations as well as the centralized proximity manager. You can find these utilities in Meru/util/. Both are python scripts that should run fine with no parameters (all the subsystem implementations are set to use the same default settings).

Example

As an example, lets say you wanted to run a two node server network. You would need to run these commands in separate terminals:

From Meru/:

 python util/small_table.py

From Meru/:

 python util/centralized_proximity_manager.py

From Meru/data/bin:

 ../../src/server --port=8888 --accounts=smalltable --proximity=central --object-store=smalltable --message-router=smalltable --reference-registry=smalltable --object-connections=smalltable

From Meru/data/bin:

 ../../src/server --port=8889 --accounts=smalltable --proximity=central --object-store=smalltable --message-router=smalltable --reference-registry=smalltable --object-connections=smalltable

Then you could connect to localhost on ports 8888 and 8889 with the client.

---Importing meshes--- hit 'l' then you can select a mesh exported from

or pick a few example meshes by typing in a URI for instance meru://cplatz@/ArchD_Triumph_01.mesh or meru://cplatz@/Plant_Big_04.mesh or meru://cplatz@/Tree_Common_trop_02.mesh in the filename field more examples are listed here http://graphics.stanford.edu/~danielrh/dns/names/global/cp/la/cplatz/