Reliable Client-Server Communication PRESENTED BY: SRIJA REDDY KASAM

Client-Server Communication It can be performed in two ways 1. Client-server communication using TCP 2. Client-server communication using RPC

A communication channel may exhibit crash, omission, timing, and/or arbitrary failures. In general , we focus on masking crash and omission failures.

Point –to –Point communication using TCP A reliable point-to-point communication can be established by using TCP protocol. TCP masks omission failures. TCP does not mask crash failures.

Communication using RPC RPC- Remote procedure calls The goal of RPC is to hide communication by making remote procedure calls that look just like local ones. The RPC mechanism works well as long as both the client and server function perfectly.

There are 5 classes of failures in RPC The client unable to locate server. (so no request can be sent.) The request message from client to server is lost.(so no response is returned by the server to the waiting client.) The reply message from the server to the client is lost.(the service has completed, but the results never arrive at the client) The server crashes after receiving a request.(and the service request is left acknowledged, but undone.) The client crashes after sending a request.(and the server sends a reply to a newly-restarted client that may not be expecting it.)

1. Client unable to locate server Problem- When server goes down The RPC system informs the client of the failure Solution- error raise an exception Java- division by zero C- signal handlers

2. Request message from client to server is lost. 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. If request is not lost, we should make sure server knows that its a retransmission.

3.Reply message from server to the client is lost. 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. So server has to maintain the sequence number while sending the reply.

4. Server crashes after receiving request The client cannot tell if the crash occurred before or after the request is carried out

Methods involved Remote operation: print some text and (when done) send a completion message. Three events that can happen at the server: Send the completion message (M), Print the text (P), Crash (C).

. These three events can occur in six different orderings: M →P →C: A crash occurs after sending the completion message and printing the text. M →C (→P): A crash happens after sending the completion message, but before the text could be printed. P →M →C: A crash occurs after sending the completion message and printing the text. P→C(→M): The text printed, after which a crash occurs before the completion message could be sent. C (→P →M): A crash happens before the server could do anything. C (→M →P): A crash happens before the server could do anything.

Strategies to be followed 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. 4. When ack - request is retransmitted. Another technique is the inclusion of additional bits in a retransmission to identify it as such to the server.

5 . Client crashes after sending request When a client crashes, and when an ‘old’ reply arrives, such a reply is known as an orphan. Four orphan solutions have been proposed: extermination (the orphan is simply killed-off). reincarnation (each client session has an epoch associated with it, making orphans easy to spot). gentle reincarnation (when a new epoch is identified, an attempt is made to locate a requests owner, otherwise the orphan is killed). expiration (if the RPC cannot be completed within a standard amount of time, it is assumed to have expired).

CONCLUSION Techniques for reliable communication – Use redundant bits to detect bit errors in packets – Use sequence numbers to detect packet loss – Recover from corrupted/lost packets using acknowledgements and retransmissions