communication mechanism in client server model
TRANSCRIPT
![Page 1: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/1.jpg)
Client Server Communication
Presented to :
Sir Ahmad Mohsin
Deliverers :
Athar kashan 131356
Junaid Lodhi 131357
Ahsan Saleem 131358
![Page 2: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/2.jpg)
Topics
• Client Server Communication
• Strategies of Communication
• Sockets
• Pipes
• RPC (Remote Procedural Calls)
![Page 3: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/3.jpg)
![Page 4: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/4.jpg)
![Page 5: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/5.jpg)
![Page 6: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/6.jpg)
![Page 7: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/7.jpg)
![Page 8: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/8.jpg)
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.
![Page 9: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/9.jpg)
Socket Communication
![Page 10: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/10.jpg)
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
![Page 11: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/11.jpg)
General View of Pipe
![Page 12: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/12.jpg)
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.
![Page 13: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/13.jpg)
Ordinary Pipe
![Page 14: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/14.jpg)
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;
![Page 15: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/15.jpg)
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();
![Page 16: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/16.jpg)
• 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]);
![Page 17: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/17.jpg)
• 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
• }
![Page 18: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/18.jpg)
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; }
![Page 19: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/19.jpg)
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.
![Page 20: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/20.jpg)
Named pipes
![Page 21: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/21.jpg)
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
![Page 22: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/22.jpg)
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.
![Page 23: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/23.jpg)
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.
![Page 24: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/24.jpg)
ProcedureCall
Remote
![Page 25: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/25.jpg)
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
![Page 26: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/26.jpg)
26
IndexMechanism
Architectural Hurdles
Solution
Ahsan
![Page 27: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/27.jpg)
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
![Page 28: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/28.jpg)
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
![Page 29: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/29.jpg)
29Ahsan
![Page 30: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/30.jpg)
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
![Page 31: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/31.jpg)
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
![Page 32: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/32.jpg)
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
![Page 33: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/33.jpg)
• 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
![Page 34: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/34.jpg)
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
![Page 35: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/35.jpg)
![Page 36: communication Mechanism in Client Server Model](https://reader035.vdocuments.us/reader035/viewer/2022062406/55caa47ebb61eb905d8b4724/html5/thumbnails/36.jpg)
ThankYou