Below you find a brief description for each project task.

A student may also define a project tasks of his own as long as the task fulfills the general requirements. A plain client-server solution is not enough. A 3-tier solution would do, for example, client-proxy-server with several clients and possibly with several servers. In general, a some kind of distributed solution is recommended.

A student gives a detailed description of the task at hand approximately within one week after the distribution of the tasks. The instructor will give the actual deadline for this. This description should contain all necessary clarifications and details to accurately define the requirements and the scope of the task that will be agreed on with the instructor. The detailed desctiption may differ from the original description as long as the requirements can be fulfilled and agreed with the instructor.

During the first four-five weeks a design document is prepared. It will be reviewed and given a grade (max 12 p / 30 p). It consists of the detailed task description and the design. The focus is in the description of the communication, that is, the application protocol design of the task (message formats, protocol operations, handling of various potential error conditions, etc). A high level design is enough for the internal structure of each component (process), including main data structures and actions.

The maximum points that you may earn with the project is 30 points. Design max is 12 p, the programming quality, functionality and documentation of the final project code yields max 15 p. In addition, each student is given two design documents prepared by other students for reviewing. Based on the comments given on these documents max 3 points can be earned.

Tasks:

1 Name Service

Implement a simple distributed name service. A name server is run in several nodes (at least 3 instances) and they maintain a name database consisting of several object classes (e.g., services, files). The name database is distributed such that each name object is stored on one of the servers only.

A name service client contacts one of the servers and receives same service regardless of which server it communicates with. The address(es) of the name server(s) that the client may contact can be stored in a configutration file local to the client.

The name service should implement the following operations:

• lookup - the client gives the name of the object to lookup and the service returns the attributes of the given object. This operation should have an efficient implementation to ensure fast response
• Update operations: register, unregister and modify
• register creates a new object with given name and attribute values
• unregister removes an object with given name
• modify updates the attribute values of an existing object except name [and type]

For serialization, if needed, a simple solutions is enough (e.g., a centralized lock server).

2 Distributed Dictionary

Implement a distributed dictionary service (at least 3 servers, cf. the task no: 1). The elements (objects) in the dictionary consist of a tuple (term, description).

The following operations are supported:

explain <term> -> <description>
insert <term> <description>
remove <term>
update <term> <new description>

The distribution of the dictionary service is transparent to the client, that is, the client may contact any of the servers and it receives the same service. The distribution of the objects may follow the same principles as in task 1.

3 File Service

Implement a simple distributed file service with which you may store and retrieve files from several nodes (servers). Implement the following commands:

• ls (dir) Lists the file names, location, size and the date last modified
• cat <name> prints the content of the file to stdout
• save <name> creates a file with name <name> and reads the content of the file from stdin
• rm <name> removes file <name>
• mkdir <dir> creates a directory with name <dir>
• rmdir <dir> removes a directory with name <dir>
• cd <dir> moves to the directory <dir>
• cp t1 t2 copies the content of the file t1 to the content of file t2

The root directory of the file system may be fixed and each of the servers may have their own subdirectory/ies (subtree) directly under the root. Each server manages their own subtree(s) in the distributed file service.

4 Load Balancing and Remote Commands

The program makes queries (using UDP) about the load level on different hosts and executes the given command in the host that has "lowest" load. The input for the command and the output from the command is delivered from/to the client. The client host runs a load balancing daemon that cooperates with the load balancing daemons on other hosts, running the same algorithm(s).

The program should implement at least two out of five different algorithms (cannot be Random and Round-Robin) for selecting the host to run the command. The algorithm to use is given as a command line argument. The first two algorithms apply the following condition:

if  local load < threshold  or the command has visited MAX_VISITS hosts
then
   execute the command on this host
else
   send the command to another host for execution

Algorithm
Random:	Select randomly the next host where to send the command
Round-Robin:	Select the next host to send the command from a Round-Robin list (each host maintains its own Round-Robin list)
Query the fastest:	Send a query to all other hosts and execute the command on the host that replies first
Query Load:	Send a query to all other hosts and select the host with lowest load
Update Load:	Each host updates its current load reqularly to the other hosts and the selection is based on the latest status information available on the client host

It is useful for the user to learn on which host the command was executed. You may assume that the command takes its input from stdin and prints its results to stdout and stderr, so these streams are directed from and to the client host. You may also assume that all hosts have access to the same files (use NFS file system on fs). You may also negotiate using a load balancing algorithm of your own with the instructor.

5 Distributed make

The program employs make command (make -n) in order to produce a list of commands that it executes in parallel potentially on N different hosts. The output of the commands are delivered to the client program (on client host). The program may select the hosts on which the commands are executed using the "Update Load" algorithm defined in the previous task. N hosts with lowest load are selected.

The commands are executed in parallel if they belong to the same group. Commands in the next group can be executed only after all commands of the previous group have been executed. If an error occurs, parallel execution need not to be terminated but the execution of the next groups should be cancelled. For example, program C is compiled from modules a.c and b.c so that the commands to execute with make are as follows:

1. cc -c a.c -> produces a.o
2. cc -c b.c -> produces b.o
3. cc a.o b.o -o c -> Produces C

With this example, the commads 1 and 2 can be executed in parallel. They should belong to the same group (G0) and the command 3 should be in a group of its own (G1) that is executed after G0. When a Makefile is written, we add the corresponding group in front of the command(s) in the group using "echo" command. So, the Makefile for the example given above could be:

C: a b
  @echo G1
  cc a b -o C
a: a.c
  @echo G0
  echo compiling a
  cc -c a.c
b: b.c
  @echo G0
  echo compiling b
  cc -c b.c

The program runs first the command make -n < Makefile> in order to get output for all commands to execute. For example the Makefile above would give:

#group 1
echo G0
echo compiling a
cc -c a.c
echo G0
echo compiling b
cc -c b.c

#group 2
echo G1
cc a b -o C

The client for the distributed make takes this list as input and exectes the commands group by group. The group for a command is indicated with the preceeding line "echo Gn". If the Makefile is correctly written the numbers are ascending. With this example, the program would execute commands "echo compiling a" and "cc -c a.c" on host H1 and commands "echo compiling b" and "cc -c b.c" on host H2 in parallel. If both compilations are successful, it will also execute the command "cc a b -o C" either on host H1 or H2 (depending on the load).

The distributed make can be defined as follows: hmake <makefile> <node-list>; If the "node-list" listing the candidate hosts for execution is not given, a default list can be used. You may assume that all components of the program have access to the same file system (use NFS file system on fs)

6 Calendar

Implement a simple distributed multiuser calendar system. Each user may add appointments and other events in the calendar for herself/himself as well as to the other users. The calendar of a user is stored in a single calendar server only. A calendar server could use a calendar control server to register new users (and their calendars). The calendar control keeps track of the (active) users.

calendar control can be a centralized server that maintains a calendar database with an entry for each user:

User  Host  UDP-port

A client program may lookup the calendar for each user with simple commands. You may implement also a group event: an event that is added to the calendar of each user belonging to the group. If the event cannot be added at least to one user's calendar, then no event is marked to anyone. The calendar marks should be short and simple and one hour slots can be used, for example. A calendar covering a single week is good enough.

Operations:

• List calendar (own/another person)
• Add/Remove event from a calendar
• List users
• Add group
• Add group event

Queries to the calendar control are implemented using UDP. The client program communicates only with its own calendar server and the calendar servers communicate with each other (most likely with TCP).

7 Game

Implement a simple distributed shipbattle game that N users can play with each other. You may have several games running simultaneously. The game controller is a server on a single host.

The game controller accepts players and gives each player the ships (e.g., 5 ships, each allocating 3 slots in the "ocean"). The size of the "ocean" may depend on the number of the players.

Each player has two processes: 1) the game server that maintains the location of the ships of the player and communicates with the other game servers and 2) the user interface process (client). The client communicates only with its own game server. The user (player) cannot impact the operation of the game server in any other way than what has been defined in the client - game server interface. The game server representing the client only knows the loacation of the ships of that client. All ships are still in the same "ocean".

A player (user) may:

• Shoot a given slot in the ocean and learns if it hit a ship belonging to someone else.
• Move (and rotate) her/his own ships, if the ship is not hit. Collisions of the ships are not allowed. Insted, the program informs the user about the potential collision.

Each player may take actions at will but the game servers allocate turns in round-robin fashion. Each turn, however, has timeout (e.g., 1- 15 sec) after which the player loses her/his turn if no action has arrived at the game server in time.

User interface can implement an automated player (auto pilot)

The system need not to recover from unexpected termination of a single game server, but if a client leaves the game early it should be announced to other plyers and the game should continue (game server continues without the user). Use of broadcast/multicast between game servers is no allowed.

8 Distributed Online Meeting System

Like above, but now the turns are for giving the floor to meeting attendants. A chairman may be implemented to control the floor.