- 31 Mar, 2021
- 0 Comments
- 2 Mins Read
Assignment 3: Multiple Clients/Servers
In this lab, you will improve on the multiple client-server room reservation solution from
Assignment 2. Again, you can develop Assignment 3 from scratch, base it on your solution to
Assignment 2, or use the published sample solution (however, as before, I won’t be answering
questions about the implementation, as with many other “free” software, the rule is “use at your
own risk”). The key changes in this assignment are to improve the performance in two ways:
(1) Introduce client-side caching
(2) Have the set of servers elect a leader, who will be the only server to actively respond to
user requests
Similar to Assignment 2, each server needs to be able to handle multiple clients (including
delaying/sleeping a while after the reply to model the effect of heavy compute load and long
network latency) and a client may interact with a number of fully replicated servers.
Caching Clients
So far, a client makes a request to the server for every command. In networks/scenarios where
the client is potentially far away from a server, this may introduce high latencies. Many
distributed applications use caching to overcome that problem. In essence, caching means that
results returned from a server are stored closer to (or, in the extreme, at) the client. If a client
repeats a request, the reply is available locally and can be returned much faster. Of course, such a
scheme will have to worry about changes to the data on the servers (which will invalidate cached
data). The textbook discusses the motivation for caching in the WWW in Chapter 2, more
specifically Section 2.2.5 in the 7th edition of the textbook. Devise and implement a caching
scheme for the room reservation application and implement it in the client.
Server Groups with Leader Election
In the Assignment 2 solution, each server replies to a client request, which is clearly suboptimal.
Among other issues, we had to devise a (clever?) way to suppress multiple answers. This was
done because the servers do not know about each other’s existence. In this assignment, the group
of servers should
• Elect a group leader, who will reply on behalf of the collection of servers to client requests.
A number of different leader election algorithms exist, for a survey see
http://www2.cs.uregina.ca/~hamilton/courses/330/notes/distributed/distributed.html. The
sample solution implements a simplified version of the Bully Election Algorithm but you are
welcome to choose another approach or to design your own solution as well. Your solution
should select the process with the highest unique ID (see below) as group leader.
• Monitor the group leader to ensure it has not crashed/disappeared. If this were to happen, a
new leader needs to be elected. Such a mechanism is usually termed a “failure detector” or
“heartbeat message”. You may want to explore some possible strategies doing a search for
terms such as “distributed systems failure detector” or “distributed systems heartbeat
mechanism”