Communication Between Process

You might also like

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 33

Communication Between Process

Unstructured Communication
 use shared memory or shared structure

Structured Communication
uses explicit messages (IPCs)
Layered Protocols (I)

Reference model for networked communication


Layered Protocols (2)
Client-Server Communication

 Assume that you are developing a client-server


application:
 How to let the two processes (client and server)
located on two machines communicate with each
other?
 Socket programming: using functions like connect(sd,
(struct sockaddr *)&sin, sizeof(sin)), write(sd, buf,
strlen(buf)) etc.
Remote Procedure Calls (RPC)

• Avoid explicit message exchange between processes


• Basic idea is to allow a process on a machine to call
procedures on a remote machine
– Make a remote procedure possibly look like a local one

• Original paper on RPC:


– A. Birrell, B Nelson, “Implementing Remote Procedure
Calls”, ACM Symposium on Operating System Principles,
1984
Conventional Procedure Call
• How are parameters passed in a local
procedure call
– E.g., #include <sys/types.h>
#include <unistd.h>
...
char buf[20];
size_t nbytes;
ssize_t bytes_read;
int fd;
...
nbytes = sizeof(buf);
bytes_read = read(fd, buf, nbytes);
Conventional Procedure Call

Figure 4-5. (a) Parameter passing in a local procedure call: the


stack before the call to read. (b) The stack while the called
procedure is active.
Remote Procedure Calls (RPC)

How are parameter passed in a remote procedure call,


while making it look like a local procedure call?
Client and Server Stubs

Principle of RPC between a client and server program.


Steps of a Remote Procedure Call
1. Client procedure calls client stub in normal way
2. Client stub builds message, calls local OS
3. Client's OS sends message to remote OS
4. Remote OS gives message to server stub
5. Server stub unpacks parameters, calls server
6. Server does work, returns result to the stub
7. Server stub packs it in message, calls local OS
8. Server's OS sends message to client's OS
9. Client's OS gives message to client stub
10. Stub unpacks result, returns to client
Passing Value Parameters (1)

2-8

Steps involved in doing remote computation through RPC


Passing Value Parameters (2)
Passing Value Parameters (3)

a) Original message on the Pentium (little-endian)


b) The message after receipt on the SPARC (big-endian)
Note: the little numbers in boxes indicate the address of each byte
Passing Value Parameters (3)

a) Original message on the Pentium (little-endian)


b) The message after receipt on the SPARC (big-endian)
c) The message after being inverted (integer 5, string: “LLIJ”)
Note: the little numbers in boxes indicate the address of each byte
Passing reference parameters
– What is Call By Value and Call By Refernce?
– Example: call foo(int, int * ) or read(fd, buf,
nbytes)
– Call by copy/restore

– The dreaded “pointer problem”


• Linked list
• Complex graph

Machine B
Machine A
Copy value a and contents of loc b
a into a’ and loc b’ a’
b Return Copy contents of loc b’ into b
b’

foo(a, &b ) Call foo(a, &b’ )


Marshalling
Values must cross the network
Machine formats differ
– Integer byte order
• Little-endian or big-endian
– Floating point format
• IEEE 754 or not

Marshalling  transferring data structure used in remote


procedure call from one address space to another.
Define a “network format”, for example following XDR
(eXternal Data Representation) standard
http://www.ietf.org/rfc/rfc1832.txt
RPC: The basic mechanism

Client process Server process 1. Client calls a local procedure on the


client stub
Client Server
routines routines
2. The client stub acts as a proxy and
1 5 marshalls the call and the args.

Client stub
Server 3. The client stub send this to the
stub
2 remote system (via TCP/UDP)
RPC RPC
4
runtime runtime 4. The server stub unmarshalls the call
and args from the client
Process Process
kernel kernel
5. The server stub calls the actual
3 6 procedure on the server
Network Network 6. The server stub marshalls the
routines routines
reply and sends it back to the client

Source: R. Stevens, Unix Network Programming (IPC)


Vol 2, 1998
Example1: A Time Server Interface
struct time {
int seconds;
int minutes;
int hours;
int day;
int month;
int year;
char timezone[4];
}
int gettime(t); struct time *t;
int settime(t); struct time *t;
Example1: Client Stub for Settime
int settime(t); struct time *t; {
char *p, message[32];
int stat;

p = message;
p = put_int(p, SETTIME);
p = put_int(p, t->seconds);
p = put_int(p, t->minutes);
p = put_int(p, t->hours);
p = put_int(p, t->day);
p = put_int(p, t->month);
p = put_int(p, t->year);
p = put_string(p, t->timezone, 4);
stat = do_operation(“time_server”, message, 32);
if(stat == SUCCESS) get_int(message, &stat);
return(stat);
}
Example1: Server Stub (1)
void main_loop() { p = get_int(p, &t.minutes);
char *p, message[32]; p = get_int(p, &t.hours);
int len, op_code; p = get_int(p, &t.day);
struct time t; p = get_int(p, &t.month);
p = get_int(p, &t.year);
for(;;) { p = get_string(p, &t.timezone, 4);
len = receive_request(message, 32); len = settime(&t);
if(len < 4) { put_int(message, len);
/* error handling code */ len = 4;
} break;
p = message; case GETTIME:
p = get_int(p, op_code);
switch(op_code) { /* code for unmarshalling and
case SETTIME: calling gettime */
if (len < 32) { }
/* error handling code */
} send_reply(message, len);
p = get_int(p, &t.seconds); }
Writing a Client
and a Server

Figure 4-12. The steps in writing a client and


a server in DCE RPC
DCE: Distributed Computing Environment
Binding a Client to a Server (1)

• Registration of a server makes it possible for a


client to locate the server and bind to it.

• Server location is done in two steps:


1. Locate the server’s machine.
2. Locate the server on that machine.
Binding a Client to a Server (2)

Figure 4-13. Client-to-server binding in DCE.


Asynchronous RPC (1)

2-12

a) The interconnection between client and server in a traditional


RPC
b) The interaction using asynchronous RPC
Asynchronous RPC (2)

2-13

A client and server interacting through two asynchronous RPCs


LPC v.s. RPC
• Global variables

• Client and server fail independently


– RPC: requires code to deal with server crashes
When Things Go Wrong
• Semantics of remote procedure calls
– Local procedure call: exactly once
• How many times a remote procedure call may be
called?
• A remote procedure call may be called:
– 0 time: server crashed or server process died before
executing server code
– 1 time: everything worked well
– 1 or more: due to excess latency or lost reply from server,
client retransmitted
• Exactly once may be difficult to achieve with RPC
RPC Semantics
• Most RPC systems will offer either:
– at least once semantics
– or at most once semantics
• Understand application:
– Illustrate some applications that “at least once” is
suitable?
• Idempotent functions: may be run any number of times
without harm
– Illustrate some applications that “at most once” is
suitable?
Request For Comment Link
 RFC 1831: RPC Specification

 RFC 1832: XDR Specification


In-Class Exercises (I)
1. C has a construction called a union, in which a field of a
record (called a struct in C) can hold any one of several
alternatives. At run time, there is no sure-fire way to tell
which one is in there. Does this feature of C have any
implications for remote procedure call? Explain your
answer.

If the runtime system cannot tell what type value is in the


field, it cannot marshal it correctly. Thus unions cannot be
tolerated in an RPC system unless there is a tag field that
unambiguously tells what the variant field holds.
In-Class Exercises (II)
2. One way to handle parameter conversion in RPC systems is to
have each machine send parameters in its native representation,
with the other one doing the translation, if need be. The native
system could be indicated by a code in the first byte. However,
since locating the first byte in the first word is precisely the
problem, can this actually work?

First of all, when one computer sends byte 0, it always arrives in


byte 0.Thus the destination computer can simply access byte 0
(using a byte instruction) and the code will be in it. An alternative
scheme is to put the code in all the bytes of the first word. Then no
matter which byte is examined, the code will be there.
Example: Writing a client and a server (1)

/* interface.x */
/* Example Interface Definition */
struct square_in {
long arg;
};

struct square_out {
long result;
};

program SQUARE_PROG {
version SQUARE_VERS {
square_out SQUAREPROC( square_in ) = 1; /* Procedure number = 1 */
} = 1; /* Version number = 1 */
} = 0x31230000; /* program number */

Source: R. Stevens, Unix Network Programming (IPC)


Vol 2, 1998
Example: Writing a client and a server (2)

interface.x

rpcgen

interface.h

Client Main interface_clnt.c interface_xdr.c interface_svc.c Server.c


(client stub) (Server stub)

Runtime lib
Client Server

Source: R. Stevens, Unix Network Programming (IPC)


Vol 2, 1998

You might also like