methods of communication in client server model. Sockets,remote procedural Calls and Pipes with implementation in Unix

1. Client Server
Communication
Presented to :
Sir Ahmad Mohsin
Deliverers :
Athar kashan 131356
Junaid Lodhi 131357
Ahsan Saleem 131358

2. Topics
• Client Server Communication
• Strategies of Communication
• Sockets
• Pipes
• RPC (Remote Procedural Calls)

8. 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.

9. Socket Communication

10. PIPES
A 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

11. General View of Pipe

12. 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.

13. Ordinary Pipe

14. 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;

15. 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();

16. • 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]);

17. • 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
• }

18. 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; }

19. 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.

20. Named pipes

21. 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

22. 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.

23. 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.

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 25

26. Index
Mechanism
Architectural Hurdles
Solution
Ahsan 26

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 27

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 28

29. Ahsan 29

30. Steps
1. 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 30

31. Client-side stub
 Looks like local server
function
 Same interface as local
function
 Bundles arguments into
message, sends to server-
side stub
 Waits for reply, un-bundles
results
 Returns to kernel
Server-side stub
 Looks 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 31

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 32

33. • 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.

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 34