ex2 by keralaguest

VIEWS: 13 PAGES: 3

									                                  Distributed Systems – 236351
                                   Exercise 2 – Group Sudoku
                                          Due date: 15.1.2009 at 23:55

In this exercise you are to extend the distributed system you wrote for providing Sudoku Remote/Web services
in order to support group playing and fault tolerance of the front end server. In the extended system clients can
have a group Sudoku challenge in which multiple players get the same Sudoku puzzle and try to solve it before
the rest of the players in the group. The player that solves the Sudoku challenge first - wins. In order to support
such a system, extensive changes have to be made to the client application. In addition, in order to make the
front end server fault tolerant, the system will now support multiple front end servers that will back each other
up in case of failures and share the load. Also, a naming server (with a predefined URI) will now be needed in
order for the front end servers to publish their (otherwise unknown) URIs and for the clients, back end servers
and Sudoku generator web service to receive the URIs of the currently active front end servers. All of the details
specified in exercise 1 are still valid here unless explicitly stated otherwise.


System Components
The system is composed of the following components as described in figure 1 and elaborated below.




                                                                 Clients
                       Naming Server


                                                 Internet



                LAN




              Sudoku solver:      front end servers



                    Back   Back    Back   Back                   Sudoku generator web server
                    end    end     end    end




                                                      Figure 1
Client
The system supports several concurrent clients. Each client is a console application that supports only the
following operations using a simple menu interface (the operations from ex1 should be removed):

        Create a new group - allowing the user to create a new group. The user specifies the characteristics of
         the requested Sudoku puzzle (its size, the number of empty squares), the total number of players in the
         group and the user’s name. After the group has been created (and a front end server has been notified),
         other players may join the group. When the number of players in the group reaches the number specified
         by the group’s creator. The group is “closed” to other players and the challenge begins.
        Join an existing group – a list of all of the groups that hasn’t been “closed” yet is shown to the user (after
         it has been received from a front end server). Each group is listed together with its parameters (puzzle
         size, number of empty squares and total number of players). The user can choose a group to join. The
         user is requested to enter his name before joining the group. Each user gets printed notifications
         regarding any change in the number of players in its group.

Once a challenge begins, the client application of one of the players contacts the Sudoku generator web service
and asks for a Sudoku puzzle with the requested characteristics. Once the Sudoku puzzle has been received, it
sends the puzzle to the rest of the players in the group and writes it to a file (in the same format as in ex1).
When a player gets the Sudoku puzzle from the group’s creator it writes it to a file as well. Then, the fun starts,
each player in the group is trying to solve the Sudoku puzzle as fast as possible and writes the solution to a
solution file (in the same format). When a user completes the puzzle, it enters the solution file name to the client
application and the client application checks two things:
     1. That the solution file is indeed a solution to the received Sudoku challenge (checked locally).
     2. That the solution is indeed a valid solution. This is checked by contacting a Sudoku solver front end
        server and sending it the solution. In order to support this operation the Sudoku solver front end and
        back end servers should support the operation of checking the validity of a solved Sudoku puzzle. This
        capability should be added to their interfaces.
After checking the solution entered by the client, in case the solution passes both tests, the client application
sends a message to the rest of the players in the group that says that user <name> solved the Sudoku challenge
first. Users may still work on the Sudoku challenge well after a winner has been announced, but no more
messages are sent among the group’s players after the announcement of the winner.

Clients should support front end server failure recovery and load balancing using two custom sinks.

Naming Service
The naming service should expose methods for the front end servers to publish their URIs and for clients, back
end servers and the web service a way to learn about the location of the front end servers. All other entities
communicate with the naming service over the internet using .NET Remoting. Its URI is predefined
(http://localhost:5000/NamingServer) and publically known.

Sudoku Solver Front End Server
The front end servers register their URIs at the naming server as soon as they start running. The updated list of
currently running back end servers is shared among the front end servers using group communication
(Ensemble). Each Front end server, when activated, immediately gets the updated list of back end servers from
one of the running front end servers. This way even though back end servers only register themselves at one
front end server, their existence is known to every front end server. In addition the front end servers also
manage the list of open groups opened by users in order to play group Sudoku. Namely, the front end servers
expose an interface for adding/removing a group from the groups list and for getting the updated list of open
groups. This interface is used by the clients whenever they want to create a new group, remove a group (once
the challenge has begun) or to get the updated list of open groups (in order to join one of them). The updated list
of groups is shared by the front end servers using group communication, much like the list of back end servers.

Back End Server
The back end servers learn about the URIs of the front end servers by querying the naming service over the
Internet. However, they should only register/deregister themselves at one front end server based on the idea that
the front end servers share the back end servers list using group communication.



Additional Details (in addition to those mentioned in ex1)
    1. All communications between the client applications should be made via Ensemble.
    2. You can assume there will be no partitions in the Ensemble groups.
    3. The communications within each group created by a user should be made via a separate group in
       Ensemble.
    4. You should make your custom sinks as service independent as possible and reuse them for both the
       client application and the front end server application.
    5. It is up to you to complete the design and protocol details of the system, in any case you are considering
       two alternatives – choose the one which you find easier to rational.
    6. Mistakes that have been found in your solution for ex1and do not interfere with testing/grading ex2 will
       not cause an additional reduction of points in ex2 (in case you are not sure – fix it).
    7. A FAQ list is added to the exercise. Please check it out from time to time and before asking new
       questions.

Submission
Submission is in pairs only (same pairs as in ex1) and using the electronic submission system. The submitted
filename should be ds-ex2.zip
The file should contain:
    1. A text file named submitters.txt containing the names, IDs and emails of the submitters.
    2. Another zip file with your entire Visual Studio 2005 solution.
    3. A doc/pdf/ppt file with your external documentation.
    4. A zipped folder named run.zip. The folder should contain 4 executables named (with respect to their
        roles) Client.exe, NamingServer.exe, SudokuFront.exe and SudokuBack.exe. They will all be invoked
        from the run folder using the following syntax (using the attached run_ex2.bat batch file):

       Client.exe (with no arguments)
       NamingServer.exe (with no arguments)
       SudokuFront.exe <front-port> <back-port> e.g. SudokuFront.exe 9000 8000
       SudokuBack.exe <port> e.g. SudokuBack.exe 7000

       (in the example, port 8000 is used by the front end server to expose the add/remove methods for the
       back end servers and port 9000 is used to receive requests from clients)

       The run folder must include all of the required files for the execution (e.g., dlls). In addition, the run
       folder should contain the Sudoku generator web service in an internal folder named SudokuGenerator.
       Inside this folder is the web service file named SudokuGenerator.asmx (among other files). The
       SudokuGenerator folder will be copied as is to the path c:\interpub\wwwroot\ so that the URI of the web
       service will be: http://localhost/ SudokuGenerator /SudokuGenerator.asmx

   Submit a printout of your external documentation to the course cell.

								
To top