A user runs a simulation using the "akkey" command on the user's workstation (see section ??n page 100). The parameters to the akkey command include the name of the simulation and any parameters it might require, and possibly the value of P, i.e. number of simulation engines that should be employed. The initiation of a simulation involves 3 main tasks.
1. The akkey process (running on the user's machine) makes a request for running a new simulation (LREQ) to the Directory Central process (possibly running on another machine).
2. Upon receiving the request, Directory Central process searches its Registered-
AKAROA-Machine (RAM) to nd P machines in the AKAROA domain
that are most suitable for hosting simulation engines. Next, Directory Central sends a simulation engine launch request to Local Manager process at each of the chosen machines.
Figure 6.4: Simulation Engines | Control Processes Binding
3. Upon receiving a simulation engine launch request, each Local Manager would create a new simulation engine process, and report back to the Direc- tory Central.
These tasks are performed in the following way.
The akkey-main, akkey-stub, and akkey-RPC-runtime execute on the user's machine. When the user runs a simulation with akkey, akkey-main invokes a akkey-
stub function for building a Launch Request (LREQ) datagram. This datagram would hold a specication of the type of service required, and a variable number of arguments. For akkey, the service type would be Launch Request (LREQ). The arguments would include the name of the SE executable and parameters, and the priority and hostnames of machines requested if specied by the user using the akkey option. When the LREQ datagram has been assembled, akkey-stub asks akkey-RPC-runtime to transmit the datagram to the machine that hosts the Directory central process. akkey-RPC-runtime would then add a call identier to the datagram, transmit it to the directory central process at its well known address (machine address and port number), sets an alarm. and blocks, waiting for a proper response. If a response corresponding to this call has not been received when the alarm expires, akkey-RPC-runtime timesout and retransmits the LREQ datagram1.
On receipt of the LREQ datagram, the RPC-runtime of Directory central's host machine notes the call identier in the datagram, then passes the data- gram to the Directory Central-stub. The Directory Central-stub unpacks it and makes a function call invoking the Directory Central-server procedure for simula- tion launch. Once invoked, the Directory Central-server's simulation launch func- tion searches its Registered-AKAROA-Machine (RAM) Database for the most appropriate machines for hosting the simulation processes. Having selected P
suitable machines, it makes one Simulation Engine Launch Request (SELR) call to each Local-manager-server of the selected machines. Each call by the Di- rectory Central-server is handled through the Directory Central-stub and Direc- tory Central's RPC-Runtime (on Directory Central's machine), and the Local Manager's RPC-Runtime and the Local-Manager-stub (on the Local Manager's machine).
Following the receipt of a SELR datagram, the Local-manager-stub unpacks it and makes a Simulation Engine Launch call to the Local-manager-server. Local- manager-server folks, with its child executing the requested Simulation Engine through an exec local kernel call. The parent then returns a SELA datagram to the directory central process (through its Local-manager-stub and RPC-runtime), to inform Directory central that the simulation engine was successfully launched on its machine.
After making each SELR call, the Directory Central-server updates the entry of the called machine in its RAM database, to note that machine is executing a simulation engine. Having made P SELR calls the Directory Central-server re-
1in the current implementation,up to ve retries are allowed before akkey-RPC-runtime
gives up and returns a failure indicator
turns a success indicator together with the number of machines running simulation engine processes, to its Directory Central-stub, and the results are packed into a datagram together with the call identier that accompanied the LREQ, and passed back to the blocked akkey process in the user's machine. There they are unpacked and the akkey-stub returns them to akkey-server. Next, akkey-server informs the user of a successful launch and the number of machines engaged (for SE execution), and then blocks, waiting for simulation completion.
Meanwhile, each of the simulation engines (typically on separate machines in the network) created by the SELR calls will make a Generator Request (GREQ) remote function call when their execution encounters the declaration of the SPEC- TRALANALYSIS object. The purpose of GREQ is twofold. This GREQ call is made by the constructor of SPECTRALANALYSIS, which in turn invokes the appropriate function in the simulation-engine-stub for assembling a GREQ data- gram, then tells simulation-engine-RPCruntime to transmit the datagram to the Directory Central process's machine and port. On receipt of a GREQ packet, the Directory Central process obtains the rst unassigned pseudo random number generator searches from its generator database (each simulation engine must use a dierent random number generator, and such that the sequences of numbers created by each generator are not correlated). Directory central would then assign it to the calling simulation engine by sending the seed dening the generator as the return value of the GREQ call. This return value is packed into a Generator Return (GRET) datagram by Directory Central-stub, and then transmitted to the calling simulation-engine's machine by Directory Central-RPCruntime. Secondly, Directory Central would update its Active Simulation Engine (ASE) database with an entry for the calling simulatin engine process. Each entry include information on the simulation's location and status.
Thirdly, if this is the rst GREQ packet received during the current simulation run, then a Directory Central sets a timer for measuring (real) simulation run time. The time taken for the parallel simulation run is recorded in default reports produced by AKAROA.
The transactions between the akkey, directory central and local manager pro- cesses in this launch phase are summarised in Fig. 6.5. The databases maintained by the Directory Central, their conceptual scheme, and their physical implemen- tation are depicted in Fig. 6.6.
Figure 6.5: AKAROA process interactions during a simulation launch.