Reliable Client-Server Communication

- Manvitha Potluri

Client-Server Communication

It can be performed in two ways

1. Client-server communication using TCP2. Client-server communication using RPC

A reliable point-to-point communication can be established by using TCP protocol.

TCP masks omission failures.

TCP does not mask crash failures.

Point –to –Point communication

RPC- Remote procedure calls

The goal of RPC is to hide communication by making remote procedure calls that look just like local ones.

Its difficult to mask RPC.

Communication using RPC

There are 5 classes of failures in RPC

1. The client unable to locate server.2. The request message from client to server

is lost.3. The server crashes after receiving a

request.4. The reply message from the server to the

client is lost.5. The client crashes after sending a request.

1. Client unable to locate server Problem- When server goes down

Solution- error raise an exception Java- division by zero C- signal handlers

Drawback- Not every language has exceptions and signals.

Exception destroys transparency.

The operating system starts a timer when the stub is generated and sends a request. If response is not received before timer expires, then a new request is sent.

Lost message – works fine on retransmission.

Many requests sent- cannot locate server. If request is not lost, we should make sure

server knows that its a retransmission.

2. Lost request messages

Some messages can be retransmitted any number of times without any loss.

Some retransmissions cause severe loss.

Solution- client assigns sequence number on requests made by client.

Drawback- Server maintains administration on each client. How long to maintain.

3. Lost reply messages

The server experiences 3 types of situations.

4. Server crashes after receiving request

Methods involved 1. Atleast once – RPC carried out >1 time.

2. Atmost once- RPC carried out<=1 time.

Example – print text request

There are four strategies 1. Never- client will never issue a request at

the risk of text not being printed. 2. Always- It can reissue a request but

results in printing twice. 3. When not ack- client decides to reissue

request to server when there is no acknowledgement that the request is sent.

3. When ack- request is retransmitted.

Strategies to be followed

With two strategies for server and four for client , there are more combinations to occur.

These are represented by M-send message completion, P- Print text, C- crash.

5. Client crashes after sending request

Orphans waste CPU cycles, lock files or tie up valuable resources. Even if the client reboots, the confusion persists.

There are mainly four solutions proposed

1. Orphan extermination- Before the client stub sends the request, a log is created which can survive crashes. After reboot the log is checked and orphan is explicitly killed.

Disadvantage- storing data in logs, locating and killing is a heavy task. Sometimes it may fail and result in grand orphans.

2. Reincarnation- Here time is divided into sequentially timed epochs. When it reboots, a new epoch is started and old orphans are removed.

solutions

3. Gentle reincarnation- Each machine checks to see if there are any remote computations running locally, and tries to find their parent. If not found it terminates.

4. Another solution is that, each RPC is given a certain amount of time. If it cannot finish another quantum is requested. After the crash it waits for certain time to reboot where orphans are terminated.

We have discussed about TCP and RPC methods. But these don’t provide high failure transparency.

In our future we can deal with ADSV(shared variable abstraction) for fault tolerant communication.

Future work

Thank you.