Client Server Communication

Presented to :

Sir Ahmad Mohsin

Deliverers :

Athar kashan 131356

Junaid Lodhi 131357

Ahsan Saleem 131358

Topics

• Client Server Communication

• Strategies of Communication

• Sockets

• Pipes

• RPC (Remote Procedural Calls)

Sockets

• A socket is defined as an endpoint for communication

• Concatenation of IP (Internet Protocol) address and port

• The socket 161.25.19.8:1625 refers to port 1625 on host 161.25.19.8

• Communication consists between pair of sockets.

Socket Communication

PIPESA pipe in computing is way of communication between more

than one process .Pipe strictly follows the Inter Process Communication.

Pipes were the one of the first mechanism in early UNIX systems.It provides one of the simplest way of communication

between different process

General View of Pipe

Types of Pipes

• Ordinary Pipes

• Named Pipes

Ordinary Pipes:

The Ordinary pipe in Operating Systems allows the two procedures to communicate in a standard way: the procedure writes on the one end (the write end) and reads on the consumer side or another end (the read-end). As a result, ordinary pipes are unidirectional, allowing only one-way communication as shown in a figure.

Ordinary Pipe

Ordinary Pipes in Unix System

#define BUFFER_SIZE 25

#define READ_END 0 // fd[0] is the read-end of the pipe

#define WRITE_END 1 //fd[1] is the write-end

int main(void)

{

char write_msg[BUFFER_SIZE]

char read_msg[BUFFER_SIZE];

int fd[2];

pid_t pid;

Example Continued

• I* create the pipe *I

• if (pipe(fd) == -1) {

• fprintf(stderr,"Pipe failed");

• return 1;

• }

• I* fork a child process *I

• pid = fork();

• if (pid < 0) { I* error occurred *I

• fprintf(stderr, "Fork Failed");

• return 1;

• }

• if (pid > 0) { I* parent process *I

• }

• I* close the unused end of the pipe *I

• close(fd[READ_END]);

• I* write to the pipe *I

• write(fd[WRITE_END], write_msg, strlen(write_msg)+1);

• I* close the write end of the pipe *I

• close(fd[WRITE_END]);

• else { I* child process *I

• }

Example Continued

• I* close the unused end of the pipe *I

• close(fd[WRITE_END]);

• I* read from the pipe *I

• read(fd[READ_END], read_msg, BUFFER_SIZE);

• printf ("read %s", read_msg) ;

• I* close the write end of the pipe *I

• close(fd[READ_END]); }

• return 0; }

In Windows

• Ordinary pipes on Windows systems are termed anonymous pipes.

• the pipe is created by using CreatePipe() function

• Functionality, they are unidirectional.

• Readfile() and Writefile() functions are used for reading and writing to the file.

Point of significance:

Note that ordinary pipes require a parent-child relationship between computing processes in both UNIX and Windows systems. This means that pipes can be used only for communication between processes on the same machine.

Named pipes

Named Pipes

• Communication can be bi-directional

• no parent-child relationship is required between process

• More than two process can communicate with each other a time

• named pipes exist after completion and termination of all the processes

In Unix

Name pipes referred to as FIFO (first in first out) in UNIX systems.

Once they created.

They appear as typical files in the file systems.

A FIFO is created with the mkfifo() system call and manipulated with open(), read(), write() and close() system calls.

FIFO supports two-way communication, only half-duplex transmission is permitted.

In Windows

• Much richer communication mechanism between processes rather than UNIX systems

• Full-duplex communication is allowed in Windows named pipe

• The communication may run from either different sides or from the same side of the pipe at a same time

• Name pipe is created with CreateNamedPipe() function, and a client can connect the named pipe using ConnectNamedPipe(). Communication over the named pipe can be accomplished using the ReadFile() and WriteFile() functions

POINT OF SIGNIFICANCE:

Windows provides the facility of the communication between processed residing on different machines.

ProcedureCall

Remote

25

Introduction

• One of the most common forms of remote service is the RPC paradigm

• The RPC was designed as a way to abstract the procedure-call mechanism for use between systemswith network connections.

• abstract the procedure-call mechanism for use between systemswith network connections.

Ahsan

26

IndexMechanism

Architectural Hurdles

Solution

Ahsan

27

Mechanism

• The semantics of RPCs allows a client to invoke a procedure on a remote host as it would invoke a procedure locally.

• The RPC system hides the details that allow communication to take place by providing a stub on the client side

• A separate stub exists for each separate remote procedure

• This stub locates the port on the server and marshals the parameters.

Ahsan

28

Stubs• Client stub

• Packs parameter into message.

• Calls : Send & Receive.

• Server Stub• Calls : Receive & Send.

• Unpacks parameter from the message.

• Details of message passing are hidden – two libraries.Ahsan

29Ahsan

30

Steps1. The client procedure calls the client stub in the normal way.

2. The client stub builds a message and traps to the kernel.

3. The kernel sends the message to the remote kernel.

4. The remote kernel gives the message to the server stub.

5. The server stub unpacks the parameters and calls the server.

6. The server does the work and returns the result to the stub.

7. The server stub packs it in a message and traps to the kernel.

8. The remote kernel sends the message to the clients kernel.

9. The client’s kernel gives the message to the client stub.

10.The stub unpacks the result and returns to the client.Ahsan

31

Client-side stubLooks like local

server functionSame interface as

local functionBundles arguments

into message, sends to server-side stub

Waits for reply, un-bundles results

Returns to kernel

Server-side stubLooks like local

client function to server

Listens on a socket for message from client stub

Un-bundles arguments to local variables

Makes a local function call to server

Bundles result into reply message to client stub

Ahsan

32

Architectural Hurdles and Solution

• One issue that must be dealt with concerns differences in data representation on the client and server machines.

• Some systems (known as big-endian) store the most significant byte first

• while other systems (known as little-endian) store the least significant byte first.

• To resolve differences like this, many RPC systems define a machine-independent representation of data.

• .Onesuchrepresentation is known as external data representation (XDR).Ahsan

• procedure calls fail only under extreme circumstances, RPCs can fail, or be duplicated and executed more than once, as a result of common network errors.

• One way to address this problem is for the operating system to ensure that messages are acted on exactly once, rather than at most once.

• First, consider “at most once.” This semantic can be implemented by attaching a timestamp to each message.

Hurdles & Sol, Continued

34

Hurdles and solutions continued,

• For “exactly once” to accomplish this, the server must implement the “at most once” protocol described above but must also acknowledge to the client that the RPC call was received and executed.

• .These ACK messages are common through out net working.The client must resend each RPC call periodically until it receives the ACK for that call.

Ahsan

ThankYou