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.
Pages to are hidden for
"ex2"Please download to view full document