B424 Client-Server

Dana Vrajitoru
B424 Parallel and Distributed Programming

Client-Server

Models Inspired from Operating Systems
Some parallel programming schemes inspired from tasks that can be a part of an operating system.

Pool of tasks
Client-server
Producers and consumers

Client-Server
A model that is similar to the previous one, only the roles of the master-workers are exchanged. This time the master is a server that can perform tasks or provide some information, or give access to some resources. The slave processes are the clients that send in requests for service.

Client-Server in General

A server is a unit that provides a service, possibly to multiple clients simultaneously.
A client is a unit that consumes the service.
The clients do not need to know the details of how the service is provided.
The server does not need to know how the data is going to be used.
Drawbacks: the server is a single point of failure.
Resources can become scarce if there are too many clients. Hard to scale.

Benefits of the System

A single server means easy protection of data.
Doesn't require the clients and the server to be physically close.
The client nodes in the network are independent, only need to communicate with the server.
Communication protocols are usually platform independent.

Architectures

One-tier architecture - simple model, offline.
Two-tier architecture - client, server, and protocol connecting them.
Three-tier architecture - GUI tier, application tier, database tier.
N-tier architectures - the application is divided into multiple logical layers. Physical tiers run on separate machines for scalability. Closed layer or open layer.

Client Types

Thick client - rich functionality
Thin client - lightweight computer, relies heavily on the server
Hybrid client

Server Types

Application server
Computing server
Database server
Web server
Email, printer, time server
ssh, sftp, rss, authentication

Client-server Implementation

Similar to the pool of tasks, only the roles of the master-workers are swapped.

A common pattern in parallel programming.

Several client processes request service in any order.

A server process loops on the following: receive a request, process the request, send the result back.

The simple model: the server receives a request and processes it right away.

Server() {
while (true) {
    Recv(request, any_source);
    client = source;
    result = Process(request);
    Send(result, client);
}
}

Client() {
while (true) {
    request = Generate_request();
    Send(request, server);
    Recv(result, server);
    Process_result(result);
}
}

A more complex model: using a queue of requests.

This model supposes that the requests come in faster then they can be executed.
The server receives the requests from the clients and stores them in a queue.
The server must also store the identity of the client when it stores the request so that it knows which client to send the result to.
The queue of requests and of clients are synchronized.
In the loop, it chooses randomly either to receive a new request, or to execute one from the queue. Instead of this, the server can be implemented using two threads: one focused only on receiving requests, one focused only on processing them. The two threads synchronize using the queues.
When the server decides to receive a new request, no client process may be sending it one, so it's better to use a non-blocking receive for the server.

Client: the same as before.

Server() {
Queue clientq, requestq;

Initiate_receive(request, any_source); // non-blocking
while (true) {
    choose randomly between
      Process_request(clientq, requestq);
      Get_request(clientq, requestq, request);
}

Process_request(clientq, requestq) {
if (!requestq.is_empty()) {
    request = requestq.dequeue();
    client = clientq.dequeue();
    result = Process(request);
    Send(result, client);
}
}

Get_request(clientq, requestq, request) {
if (Received(request)){
    client = source;
    clientq.enqueue(client);
    requestq.enqueue(request);
    Initiate_receive(request, any_source);
}
}

In a more complex model, we could sort the tasks by order of priority in the queue. To avoid a deadlock, the priority of any task in the queue should increase with time.

Peer to Peer Systems

An alternative to the client-server model where the clients are also repositories or resources and can contribute to the network.
Typical applications: Skype, software updates for massively multi-client systems.
Some specialized (super)nodes keep the system working, connecting a node that needs a resource with one that might have it.
Both are examples of the idea of modularity.