Distributed Implementation

In this stage, you are required to create an implementation that uses a number of AWS nodes to cooperatively calculate the new state of the Game of Life board, and communicate state between machines over a network.

Below is a series of suggested steps for approaching the problem, but you are not required to follow this sequence, and can jump straight to implementing the more advanced versions of the system if you feel confident about it.

Your implementation will be marked against the success criteria outlined here.

Step 4

Finally, the local controller should be able to manage the behaviour of the Gol engine according to the following rules:

• If s is pressed, the controller should generate a PGM file with the current state of the board.

• If q is pressed, close the controller client program without causing an error on the Gol server.

  NOTE: Behaviour of new controller connected

  A new controller should be able to take over interaction with the Gol engine.
  Note that you are free to define the nature of how a new controller can take over interaction. Most likely the state will be reset.
  If you do manage to continue with the previous world this would be considered a form of fault tolerance.

• If k is pressed, all components of the distributed system are shut down cleanly, and the system outputs a PGM image of the latest state.

• If p is pressed, pause the processing on the AWS node and have the controller print the current turn that is being processed.
  If p is pressed again resume the processing and have the controller print Continuing.

  NOTE: It is necessary for q and s to work while the execution is paused.

Test

To test the visualisation and control rules, type the following in the terminal of your local controller.

Test with SDL window

go test -v -run TestKeyboard -sdl

Test without SDL window

go test -v -run TestKeyboard

You can also run the program and test the control rules manually by typing the following in the terminal of your local controller.

go run .