Start of Game - Pyosch/powertac-server GitHub Wiki

up

From a Broker's standpoint, a game starts when it has its bootstrap data and clock parameters. This discussion describes a plan to get to that point.

There are a number of things that have to happen before a game can start. The server process needs to configured and started. Bootstrap data for a game has to be generated. Brokers must log in. Bootstrap data must be distributed to brokers. Finally, a game can start. Multiple games can be run one after the other in a single process.

Server configuration is done with the Spring xml config file, and specifies the set of modules included in the server (such as the complement and configuration of customer models) along with potentially a number of parameters.

Once a server has started, or after the completion of a previous game, a new game can be configured. Given a web interface as on the Grails prototype, this configuration can be done by setting parameters in the Competition instance (the length of a game, for example) as well as in the PluginConfig instances for the various services (the tariff publication fee, for example).

The need for and format of bootstrap data has been discussed several times, including [a discussion of load profiles](Load profiles), a Nabble discussion on initial conditions, and a more detailed writeup on initial conditions on the participant wiki. The primary complication is the need to generate bootstrap data once, offline, and then run multiple games with that same initialization. This initialization data would presumably include the random number generators as well as the load profiles, market prices, and weather data. Also, if it is being generated in a different process context from the actual game, the server configuration must be the same. We will assume that the bootstrap data is stored in a file.

Assuming we generate bootstrap data by running the simulator with the default broker as the only broker, there remain several subproblems:

• How does the simulator know that it is starting a bootstrap-generation process rather than a real simulation? It seems that this distinction must be made in CompetitionControlService, since that is where simulations are started.
• What, exactly, needs to be collected and stored as part of the bootstrap process?
• How is this data collected?
• How is the data stored between the bootstrap simulation and the start of a game?
• Given a collection of several bootstrap datasets, how do we identify them?

There are several kinds of data needed in a bootstrap dataset. For Brokers, we need

• List of Customer models, with population, capabilities (consumption, production, electric vehicles, parameters for controllable loads/sources).
• For each model, production/consumption history for each timeslot in the bootstrap period.
• Weather reports for the bootstrap period, since weather may affect both production and consumption.
• Wholesale market prices for the net power supplied to the customers in each timeslot.

To enable the server to start a game that is a credible continuation of the bootstrap period, the CompetitionController will need

• The Competition instance, which includes the number of timeslots in the bootstrap period, and clock parameters including the simulation time at which the bootstrap period started.
• Some way to confirm that specific aspects of the current configuration are identical to the configuration that generated the bootstrap data. At a minimum, this includes the customer model configuration, the weather dataset being used, and the configuration of the gencos supplying the wholesale market. If all of this is determined by the content of PluginConfig instances, then that would be enough, as long as the PluginConfig instances of the various customer models that might be installed in the server are distinguishable.

We assume for the sake of simplicity that the complete set of bootstrap data can be loaded from a single file. The file is a sequence of message instances, which means it can be used directly, or sent to a remote server or web-app as a sequence of JMS messages. So either the server needs to be given a reference to a file that it can find in its process environment, or it needs to be given the complete dataset as a sequence of messages.

Given the data, the server must first confirm that the current configuration is identical to the bootstrap config. This cannot be done simply by instantiating all the PluginConfig instances, because this will not guarantee that the server config is the same as the one that generated the bootstrap. Instead, it must first run the initialization process on all the InitializationService instances, and ensure that the set of PluginConfigs in the repo matches the set in the bootstrap data. The match must determine that the set of customer models and gencos in the repo is identical to the set in the bootstrap data. Once that determination is made, the instances in the repo can be replaced by the instances in the bootstrap data.

Once the server environment has been validated, brokers can be allowed to log in. In a tournament environment, it may make sense to do a simple handshake with the web-app after validation. The response from the web-app would then be the credentials of the brokers who are to be included in the upcoming simulation.

Given a set of broker credentials, or alternatively given the promiscuous login flag, brokers can be allowed to log in. But how do brokers know it's time? In SCM, agents are configured to log in to a particular server when they start. If the server cannot accept logins, because it's already running a simulation, or because it's not ready to accept logins, it replies with a login rejection and a time to retry. The server has a short window during which it will accept logins - usually it's just 15 seconds or so. In a tournament situation, SCM agents are running all the time; they attempt to log in when they start, and the server rejects the login with a message to retry later. When a server is set up for a game with a specific set of agents, it rejects the login attempts of other agents and gives them a time after the completion of the game to try again. So each agent simply keeps trying until it gets in.

In Power TAC, we want to accept logins during a short window between the loading of bootstrap data and the start of a game. But in a tournament setup, it's the web-app that actually knows which brokers are supposed to play on which servers at specific times, and so it's the web-app that brokers should be logging in to. In a research setting with promiscuous login, it should still be the web-app that accepts broker logins. So here's a rough outline of a possible broker login process:

• Broker sends credentials to web-app using http PUT.
• Web-app responds with one of [rejected, retry(n), redirect(server-url, game-token)]. A retry tells the broker how long to wait before trying again. A redirect would be issued only after the server had validated its bootstrap data and notified the web-app. It tells the broker where to find a server, and gives it a token (the game-token) by which the server can verify the broker. Presumably the token is a hash of some combination of the broker ID and some "secret" shared between the web-app and the server.
• Broker logs into sim server using the game-token given in the redirect.
• Server validates the login and either rejects it, or logs the broker in and sets up the JMS channel to the broker.

Here is an approach for handling broker login inside the server. Brokers may be remote or local -- a local broker is a broker running as a server component, which may be a very nice way to do broker development.

A broker can attempt to log in any time after the start of the pre-game phase in a simulation.

• The pre-game phase is initialized with a list of brokers that are to be included, and possibly a time limit that allow a sim to proceed if some broker cannot make it in time.
• Any attempt to log in before the broker list is initialized or after the sim starts would be rejected. It is up to the tournament scheduler to let remote brokers know when it's time to log in.
• A local broker would implement InitializationService and do its login in the initialize() method. The local broker would need to provide its Broker implementation, because it might be a subclass of Broker and therefore it would not work for the broker-proxy or competition-control to create the Broker instance.
• After initialization, but before starting the clock, the competition-control would wait for all brokers to log in. This will work as long as remote broker logins are processed in a separate thread, which should be the case.

One unanswered question is where in this process the JMS queues get created for the remote brokers.

After all the brokers have logged in (or some timeout period has passed), the web-app instructs the server to start. This could be a result of a user poking a button in a standalone research/development deployment, or could be an action taken by the tournament or experiment scheduler. At this point, the server sends bootstrap data to all brokers, and starts the sim.