The License Plate Game (Assignment 4)

Overview

Part One of the Assignment

The license plate game server will be defined using two OMG IDL interfaces that should appear in the Game module. These two interfaces should be defined as follows:

• LP_Game_Ex -- This interface defines the following operations that inherits from LP_Game and implements a particular instance of the license plate game that contains the following methods (most of which are inherited from the LP_Game base interface:
  • void initialize (in string filename) raises (Invalid_File) -- Allow a player to designate a dictionary of valid words for use with a particular session.

  • void configure (int string letter_set) raises (Invalid_Letter_Set, Not_Initialized) -- Set the current letter set for a session to the desired three letter string of letters from a license plate.

  • boolean query (in string word) raises (Not_Configured) -- Allow a player in a particular session to query whether the designated word contains the current letter set in order in the word and also exists in the dictionary. Whenever a query "matches" a word in the dictionary, the player receives 1 point - if the query doesn't match a point is subtracted.

  • Word_Iterator list_iterator () raises (Not_Configured) -- This factory returns a Word_Iterator that returns chunks of words in the session's dictionary that match the current letter set. The iterator is defined as follows:

    
        const short WORD_CHUNK_LEN = 5;
        typedef sequence<string, WORD_CHUNK_LEN> Word_Chunk;
        interface Word_Iterator {
          // This operation returns the next <chunk> of the
          // words.  If there are no more chunks, false is returned.
          boolean next_chunk (out Word_Chunk chunk);
    
          // This operation destroys the iterator.
          void destroy ();
        };
        

    The list_iterator is the only operation that should be defined in LP_Game_Ex.

  • Player_Results results () -- Return the current results for all players in a particular game, where Player_Results is defined as a sequence of Player_Result structs containing information on each player.

  • oneway void quit () -- A oneway call that informs the server that the client is done playing the game. Only when all players in a game have called quit() should the resources for that game be reclaimed. It's possible that this method will need to shutdown the ORB if LP_Game_Factory::shutdown() had been called and this is the last player to quit the last game on the server.

  The initialize(), configure(), query(), list(), results(), and quit() commands can be invoked multiple times by players of the same game, but can only run when no other commands are executing concurrently on a game.

• LP_Game_Factory -- This interface inherits defines the following factory and management operations:
  • LP_Game join (in string game_name, in string player_id) raises (Duplicate_ID, Game_Shutdown) -- Allows a player to join an instance of the LP_Game_Ex interface (or create and join the game if it doesn't already exist). This operation is passed a game_name, which is a string that identifies the game. If the game hasn't already been created, then allocate and activate a new LP_Game object containing the resources (e.g., dictionary, score table, etc.) associated with this particular instance of the game. Each player is identified by their player_id, which is assumed to be unique (the Duplicate_ID exception is raised if the player_id is not unique). This command returns an object reference to an LP_Game, which uniquely identifies the game. Note that the returned object reference could actually be to an LP_Game_Ex object - it doesn't matter as long a the client narrows things appropriately.

  • oneway void shutdown () -- A oneway call that shut downs the server process, ultimately leading to exiting the process. Only when all players and games have shutdown, however, should the server process actually exit. After shutdown() has been called, no further calls to join() should be allowed, i.e., it should raise the Game_Shutdown exception.

• Implement the IDL files as described above and run them through TAO's IDL compiler to make sure they are correct.
• Create the servant classes that implement the servant skeletons generated by the IDL compiler. You don't need to actually implement the methods in these servant classes yet, however - that's what you'll do in Part Two. You might check out the -GI flag supported by TAO's IDL compiler.
• Create "dummy" files for all the rest of your program, i.e., these don't need to do much of anything yet, though it would help you if they at least compile.
• Create the appropriate Linux Makefile or MSVC++ project build file that can successfully build the dummy files and generated files, etc. You should start by looking at the example GNUmakefile for program 2 and simply "cut and paste" it and replace/add the necessary files.

Part Two of the Assignment

Server Application

1. Initializes the concurrency model of the ORB based on the contents of its svc.conf file.

2. Initialize the ORB, get a locality constrained object reference for the RootPOA, and activate the POA manager.

3. Create and activate an instance of the LP_Game_Factory object and write its object reference to a file. If you are a graduate student, please replace the use of the file to exchange object references with the CORBA Naming Service, which is implemented in TAO.

4. Run the ORB's event loop, which will perform the appropriate operation designated by the type of operation received from the client. Naturally, you'll need to make sure that the game-specific resources used in your server are protected properly [ACE_RW_Thread_Mutex and/or ACE_Thread_Mutex] from race conditions resulting from multi-threading.

5. You'll need to carefully reference count the number of threads that are accessing session resources so that your server behaves correctly when clients send quit() and shutdown() commands.

Client Application

1. Initialize the ORB.

2. Read the object reference for the LP_Game_Factory from a file and narrow it properly.

3. Read commands from the user's standard input, convert these into the appropriate asynchronous operation calls to the LP_Game_Factory and LP_Game_Ex objects. It's recommended that you use a state machine on the client side to keep track of when you can invoke each operation, e.g., you can't invoke any operations on an LP_Game_Ex object until the reply for join() is received. Note that since the LP_Game_Factory::join() operation returns an LP_Game object reference you'll need to narrow this to an LP_Game_ExUse the ORB's event loop via the CORBA::ORB::work_pending() and CORBA::ORB::perform_work() operations to receive the reply and display it to the standard output of the client.

4. When a client is finished playing the license plate game, it should call quit() so the server has a chance to reclaim the game resources.

Concluding Remarks

Please see the online help for information on how to setup your development environment on Vanderbilt University's Linux computing system.

Last modified 10:24:19 CST 05 December 2007