Upload
regina
View
30
Download
4
Tags:
Embed Size (px)
DESCRIPTION
CSE 124 Networked Services Fall 2009. B. S. Manoj, Ph.D http://cseweb.ucsd.edu/classes/fa09/cse124. Some of these slides are adapted from various sources/individuals including but not limited to the slides from the text book by Peterson and Davie and IETF RFCs, IEEE/ACM digital libraries. - PowerPoint PPT Presentation
Citation preview
CSE 124 Networked Services
Fall 2009B. S. Manoj, Ph.D
http://cseweb.ucsd.edu/classes/fa09/cse124
10/15/2009 1CSE 124 Networked Services Fall 2009
Some of these slides are adapted from various sources/individuals including but not limited to the slides from the text book by Peterson and Davie and IETF RFCs, IEEE/ACM digital libraries. Use of these slides other than for pedagogical purpose for CSE 124, may require explicit permissions from the respective sources.
Announcements• Programming Assignment 1
– Due on 23rd October
• Week-2 Homework – Due on 15th October
• First Paper Discussion – Discussion on 29th October– Write-up due on: 28th October – Papers will be online soon
10/15/2009 2CSE 124 Networked Services Fall 2009
Remote Procedure Call (RPC): An Application layer protocol for
Distributed Computing
10/15/2009 3CSE 124 Networked Services Fall 2009
Local and Remote Procedure Call
In the local procedure call– The caller places arguments to
a procedure in some well- specified location
– It then transfers control to the procedure
– Eventually regains control
– The results of the procedure are extracted from the well- specified location
– The caller continues execution
Remote procedure call• The caller process sends a message
to the server process • The message includes the
procedure's parameters• Caller process waits (blocks) for a
reply message• The reply message includes the
procedure's results• When the reply message is
received – the results of the procedure are
extracted and– caller's execution is resumed
• Essentially, one thread of control – logically winds through two
processes: • the caller's process• the server's process10/15/2009 4CSE 124 Networked Services Fall 2009
Host A
Procedure Call
0x450x460x470x48
0x490x500x51
0x5450x5460x5470x548
Client Program
call proc()
proc()
return
Client Program continues
Host B(Server)
Host A(Client)
0x450x460x470x48
0x490x500x51
0x5450x5460x5470x548
Client Program
call remote proc()proc()
return
Client Program continues
Remote Procedure Call
10/15/2009 5CSE 124 Networked Services Fall 2009
RPC Vs Client-Server messages• Common Client-Server Message Transaction
– Client sends a request message– Client blocking to wait for a reply– Server responds with a reply message– The response is mainly information (files, status, or data)
• RPC– Enables procedure calls without regard to its location (remote)– Follows semantics of a local procedure– Also called Remote Method Invocation (RMI)
• When procedures are methods of remote objects– Usually a blocking call to a remote procedure– Popular mechanism for building distributed systems– A type of protocol than a particular protocol
10/15/2009 6CSE 124 Networked Services Fall 2009
RPC is more complex
• Error handling– failures of the remote server or network must be handled when using remote
procedure calls
• Global variables and side-effects– since the server does not have access to the client's address space, hidden
arguments cannot be passed as global variables or returned as side effects
• Performance– remote procedures usually operate one or more orders of magnitude slower
than local procedure calls
• Authentication– since remote procedure calls can be transported over insecure networks,
authentication may be necessary
10/15/2009 7CSE 124 Networked Services Fall 2009
Local and Remote Procedure Call
Local Procedure Call• Most often the procedures are
within the same process
• Between the Caller and called processes– there is a hardware bus or
memory
• Computing architecture– Homogeneous
• Data representation formats– Homogeneous
Remote Procedure call• Always the processes are part
of different processes
• Between the caller and called processes – There is a complex network
• Computing architectures– Heterogeneous
• Data representation formats– Heterogeneous
10/15/2009 8CSE 124 Networked Services Fall 2009
Major components of RPC
• The RPC system has two main components– An RPC Protocol
• Manages the messages sent between client and server processes
• Deals with the potentially undesired properties of the network
– A Stub Compiler• A programming language and compiler• Supports
– Packaging the arguments into a request message at the client – Translates the message back into the arguments at the server– Translates the Return values at the client
10/15/2009 9CSE 124 Networked Services Fall 2009
An RPC activity flowHost BHost A
Caller Process(Client)
Client Stub
RPC protocol
Called Process(Server)
Server Stub
RPC protocol
Arguments Arguments Return
ReplyRequestRequest
Return
Reply
The InternetThe Internet
10/15/2009 10CSE 124 Networked Services Fall 2009
Client calls a Remote Procedure• At the client
– Client calls a local stub for the procedure with the necessary arguments
– Stub • translates the arguments into a Request message
– (also known as marshalling)• invokes RPC protocol to send the Request
• At the server– RPC protocol delivers the Request message to the server stub– Server stub
• translates the Request message to the arguments • calls the procedure
10/15/2009 11CSE 124 Networked Services Fall 2009
Handling results of the RP Call• After completing the procedure call
– Server returns the results to the Server Stub– Server Stub
• Translates the results to Reply message• Pass the Reply message to the Server RPC Protocol
– Server RPC protocol • transmits the Reply message to client
– Client RPC protocol • receives the Reply message• Forwards Reply to the client stub
– Client Stub • Translates the Reply to return value (or Results)• Returns the results to the Client application
10/15/2009 12CSE 124 Networked Services Fall 2009
RPC Stub compiler
(rpcgen)
10/15/2009 13CSE 124 Networked Services Fall 2009
RPC and Network protocols • Which transport protocol is suitable to carry RPC messages
– TCP• Reliability is a plus• Not message-based communication protocol• Cannot match Requests with Replys• Does not identify processes in target machines
– UDP• More suitable than TCP• Message-based• No reliability• Does not identify processes in target machines
– RPC protocol• Is considered an application layer protocol• Runs over UDP (mostly)• Reliability is ensured • Remote processes identified• Identifies Request-Reply matches
10/15/2009 14CSE 124 Networked Services Fall 2009
RPC protocol• Key functions
– Provide a name space for uniquely identifying the procedure to be called
– Match each Reply message to the corresponding Request message
– Provide information for authenticating the caller to service and vice-versa
• Name space design– Flat
• Assigns a unique unstructured identifier (integer) to each procedure
– Hierarchical• Analogous to file path names
– Directory name and file name– File name (base name) must be unique within the directory
10/15/2009 15CSE 124 Networked Services Fall 2009
Matching Replys to Requests• Using Message ID
– Request messages carry a unique message ID field
– Reply carrying the same message ID is matched with the corresponding Request
– Down side: machine crashes can result in problem
• Using Message ID and Boot ID– Boot ID refers to the unique
number created for each OS boot process
– Restarting machines may use a different Boot ID
Req(0)
Rep(0)Crash
Client Server
Req(0)Reboot
ServerDiscardsReq(0)
Req(0, bID=0)
Rep(0,bID=0)Crash
Client Server
Req(0, bID=1)RebootServerrepliesReq(0, 1)
Rep(0, bID=1)10/15/2009 16CSE 124 Networked Services Fall 2009
RPC protocol challenges• To support large message sizes
– Fragmentation and reassembly – May depend on Lower layers– Best practice is to do it at RPC level
• Handle an unreliable network– By providing reliable message delivery over UDP
• Timeouts, Retransmissions, and Acknowledgements
• Implicit ACK – Reply message implies the previous Request is received– Demands sequentability of of Req/Resp messages– Performance can be affected
• To avoid performance dent by implicit ACK– Channel abstraction is used
10/15/2009 17CSE 124 Networked Services Fall 2009
• Channel abstraction helps performance improvement
– Within a channel Req/Reply messages are sequential
– Implicit ACK is feasible within the channel• A Request implies previous Reply is received
– Limited to one transaction at any given time
– Channel ID is included in every given message
RPC protocol challenges (contd)
10/15/2009 18CSE 124 Networked Services Fall 2009
• Handling an unreliable server– Server may crash before Reply– Server may be slow
• How can a client distinguish between slow and dead servers– Client can send an “Are you Alive?”
• Server ACKs– Server can send “I am still alive”
• Will cause the server to implement large number of timers
• Not scalable – Client-side solution is more scalable
RPC protocol challenges
10/15/2009 19CSE 124 Networked Services Fall 2009
• Reliability can be enhanced by Server Semantics• At-most-once
• For every Req message, at most one copy is delivered to the server
• Possibility for missing message delivery • Exactly-once• Idempotent
• Server RPC– Server RPC must detect and discard duplicates – Server RPC needs some state info about past Requests
• Sequence numbers (permits only one outstanding Req)
RPC protocol challenges
10/15/2009 20CSE 124 Networked Services Fall 2009
Popular RPC implementations
• SunRPC– Widely used and de facto RPC standard– Implemented for Sun NFS– Also accepted as an IETF standard (latest RFC 5531)
• DCE-RPC– Defined by Open Group (IBM, Digital, and HP)– Underlying RPC for Common Object Request Broker
Architecture (CORBA)• CORBA is a standard for distributed object-oriented systems
10/15/2009 21CSE 124 Networked Services Fall 2009
A brief comparison
SunRPC• Runs over UDP• Two tier addressing• End-point mapping service
• Does not implement At-Most-Once semantics
DCE-RPC• Runs over UDP• Two tier addressing• End-point mapping service
• Implements At-Most-Once semantics
• Provides fragmentation and reassembly
• Selective ACK scheme
10/15/2009 22CSE 124 Networked Services Fall 2009
SunRPC • Addressing
– Two-tier addressing• program number (32 bits)• procedure number (32 bits)• An NSF server may have
– Program number: 0x00100003– Procedure1:read(), Procedure-2: write(), Procedure-3:setattr()
– Each program is reachable by a UDP port• SunRPC picks up messages from the respective UDP port and call
appropriate procedures
– A port-mapper program maps programs to UDP ports• Port-mapper has a well known port number (111) and program number
(0x00100000)• Port-mapper supports program-to-port-number mapping procedure
(procedure no. 3)10/15/2009 23CSE 124 Networked Services Fall 2009
SunRPC example
• To send a Request message to NFS read procedure
– Client sends a Request message to the Port-Mapper• Port no. 111• Procedure to be invoked: Procedure-3 (program-to-port mapping)
– Port-Mapper replies with the correct port number corresponding to the NFS program
– The SunRPC client sends a Request with Procedure-6 to the new port number
10/15/2009 24CSE 124 Networked Services Fall 2009
SunRPC Message Formats XID
MsgType=CALL
RPCVersion=2
Program
Version
Procedure
Credentials(Variable)Verifier
(Variable)
Data
Data
0 31
Request
XID
MsgType=REPLY
Status=ACCEPTED
Data
Data
0 31
Reply
10/15/2009 25CSE 124 Networked Services Fall 2009
DCE-RPC
Req
Resp
Client Server
Ack
Crash
ReqClient Server
Req
Resp
Client Server
Ack
Req
Resp
Client Server
Ack
Ping
Working
WorkingPing
RequestResponseReject
PingWorkingNoCall
QuitQuACK
10/15/2009 26CSE 124 Networked Services Fall 2009
Fragmentation and Reassembly in DCE-RPC
10/15/2009 27CSE 124 Networked Services Fall 2009
An exampleNon-RPC-program.c
#include <stdio.h>int product(int x, int y)
{ return x*y;}
int main( int argc, char* argv[]){int a = 8;int b =9;Printf(“Result of multiplying %d and %d is %d.\n”, a, b, product(a,b));}
$ gcc –o Non-RPC-program.out Non-RPC-program.c
$./Non-RPC-program.out
Result of multiplying 8 and 9 is 72. 10/15/2009 28CSE 124 Networked Services Fall 2009
Distributed example RPC_product.x
Program RPC_product {version RPC_product {
int product(int, int) = 1;
} = 1 } = 0x200989123;
$rpcgen –N –a RPC_product.x$ls
$Makefile.RPC_product RPC_product.h RPC_product.xRPC_product_client.c RPC_product_server.c RPC_product.x~RPC_product_clnt.c RPC_product_svc.c RPC_product_xdr.c
Program number is defined by the user. Use range 0x20000000 to 0x3fffffff.
10/15/2009 29CSE 124 Networked Services Fall 2009
Makefile$ mv Makefile.RPC_product Makefile$ makecc -g -c -o RPC_product_clnt.o RPC_product_clnt.ccc -g -c -o RPC_product_client.o RPC_product_client.ccc -g -c -o RPC_product_xdr.o RPC_product_xdr.ccc -g -o RPC_product_client RPC_product_clnt.o
RPC_product_client.o RPC_product_xdr.o -lnslcc -g -c -o RPC_product_svc.o RPC_product_svc.ccc -g -c -o RPC_product_server.o RPC_product_server.ccc -g -o RPC_product_server RPC_product_svc.o
RPC_product_server.o RPC_product_xdr.o –lnsl
10/15/2009 30CSE 124 Networked Services Fall 2009
Binary files$ ls –l-rw-r--r-- 1 root root 1178 Oct 15 11:53 Makefile-rwxr-xr-x 1 root root 19424 Oct 15 11:57 RPC_product_client-rw-r--r-- 1 root root 833 Oct 15 11:53 RPC_product_client.c-rw-r--r-- 1 root root 8088 Oct 15 11:57 RPC_product_client.o-rw-r--r-- 1 root root 625 Oct 15 11:53 RPC_product_clnt.c-rw-r--r-- 1 root root 7504 Oct 15 11:57 RPC_product_clnt.o-rw-r--r-- 1 root root 1054 Oct 15 11:53 RPC_product.h-rwxr-xr-x 1 root root 23105 Oct 15 11:57 RPC_product_server-rw-r--r-- 1 root root 325 Oct 15 11:53 RPC_product_server.c-rw-r--r-- 1 root root 7144 Oct 15 11:57 RPC_product_server.o-rw-r--r-- 1 root root 2381 Oct 15 11:53 RPC_product_svc.c-rw-r--r-- 1 root root 11792 Oct 15 11:57 RPC_product_svc.o-rw-r--r-- 1 root root 101 Oct 15 11:52 RPC_product.x-rw-r--r-- 1 root root 100 Oct 15 11:51 RPC_product.x~-rw-r--r-- 1 root root 293 Oct 15 11:53 RPC_product_xdr.c-rw-r--r-- 1 root root 4968 Oct 15 11:57 RPC_product_xdr.o10/15/2009 31CSE 124 Networked Services Fall 2009
Header file (RPC_product.h)/* * Please do not edit this file. * It was generated using rpcgen. */#ifndef _RPC_PRODUCT_H_RPCGEN#define _RPC_PRODUCT_H_RPCGEN
#include <rpc/rpc.h>
#ifdef __cplusplusextern "C" {#endif
struct product_1_argument { int arg1; int arg2;};typedef struct product_1_argument product_1_argument;
#define RPC_product 0x20091015001
10/15/2009 32CSE 124 Networked Services Fall 2009
Client file (RPC_product_clnt.c)/* * Please do not edit this file. * It was generated using rpcgen. */
#include <memory.h> /* for memset */#include "RPC_product.h"
/* Default timeout can be changed using clnt_control() */static struct timeval TIMEOUT = { 25, 0 };
int *product_1(int arg1, int arg2, CLIENT *clnt){ product_1_argument arg; static int clnt_res;
memset((char *)&clnt_res, 0, sizeof(clnt_res)); arg.arg1 = arg1; arg.arg2 = arg2; if (clnt_call (clnt, product, (xdrproc_t) xdr_product_1_argument, (caddr_t) &arg, (xdrproc_t) xdr_int, (caddr_t) &clnt_res, TIMEOUT) != RPC_SUCCESS) { return (NULL); } return (&clnt_res);}
10/15/2009 33CSE 124 Networked Services Fall 2009
Server file (RPC_product_server.c)/* * This is sample code generated by rpcgen. * These are only templates and you can use them * as a guideline for developing your own functions. */
#include "RPC_product.h"
int *product_1_svc(int arg1, int arg2, struct svc_req *rqstp){ static int result;
/* * insert server code here */ result = arg1 * arg2; return &result;}
10/15/2009 34CSE 124 Networked Services Fall 2009
Other files (RPC_product_svc.c)/* * Please do not edit this file. * It was generated using rpcgen. */
#include "RPC_product.h"#include <stdio.h>#include <stdlib.h>#include <rpc/pmap_clnt.h>#include <string.h>#include <memory.h>#include <sys/socket.h>#include <netinet/in.h>
#ifndef SIG_PF#define SIG_PF void(*)(int)#endif
static int *_product_1 (product_1_argument *argp, struct svc_req *rqstp){ return (product_1_svc(argp->arg1, argp->arg2, rqstp));}
static voidrpc_product_1(struct svc_req *rqstp, register SVCXPRT *transp){ union { product_1_argument product_1_arg; } argument; char *result; xdrproc_t _xdr_argument, _xdr_result; char *(*local)(char *, struct svc_req *);
switch (rqstp->rq_proc) { case NULLPROC: (void) svc_sendreply (transp, (xdrproc_t) xdr_void, (char *)NULL); return;
case product: _xdr_argument = (xdrproc_t) xdr_product_1_argument; _xdr_result = (xdrproc_t) xdr_int; local = (char *(*)(char *, struct svc_req *)) _product_1; break;
default: svcerr_noproc (transp); return;}
intmain (int argc, char **argv){ register SVCXPRT *transp;
pmap_unset (RPC_product, RPC_product_interface);
transp = svcudp_create(RPC_ANYSOCK); if (transp == NULL) { fprintf (stderr, "%s", "cannot create udp service."); exit(1); } if (!svc_register(transp, RPC_product, RPC_product_interface, rpc_product_1, IPPROTO_UDP)) { fprintf (stderr, "%s", "unable to register (RPC_product, RPC_product_interface, udp)."); exit(1); }
transp = svctcp_create(RPC_ANYSOCK, 0, 0); if (transp == NULL) { fprintf (stderr, "%s", "cannot create tcp service."); exit(1); } if (!svc_register(transp, RPC_product, RPC_product_interface, rpc_product_1, IPPROTO_TCP)) { fprintf (stderr, "%s", "unable to register (RPC_product, RPC_product_interface, tcp)."); exit(1); }
svc_run (); fprintf (stderr, "%s", "svc_run returned"); exit (1); /* NOTREACHED */}
10/15/2009 35CSE 124 Networked Services Fall 2009
Other files (RPC_product_xdr.c)/* * Please do not edit this file. * It was generated using rpcgen. */
#include "RPC_product.h"
bool_txdr_product_1_argument (XDR *xdrs, product_1_argument *objp){ if (!xdr_int (xdrs, &objp->arg1)) return FALSE; if (!xdr_int (xdrs, &objp->arg2)) return FALSE; return TRUE;}
10/15/2009 36CSE 124 Networked Services Fall 2009
RPC_product_client.c (original)/* * This is sample code generated by rpcgen. * These are only templates and you can use them * as a guideline for developing your own functions. */#include "RPC_product.h"voidrpc_product_1(char *host){ CLIENT *clnt; int *result_1; int product_1_arg1; int product_1_arg2;
#ifndef DEBUG clnt = clnt_create (host, RPC_product, RPC_product_interface, "udp"); if (clnt == NULL) { clnt_pcreateerror (host); exit (1); }#endif /* DEBUG */ result_1 = product_1(product_1_arg1, product_1_arg2, clnt); if (result_1 == (int *) NULL) { clnt_perror (clnt, "call failed"); }#ifndef DEBUG clnt_destroy (clnt);#endif /* DEBUG */}
intmain (int argc, char *argv[]){ char *host;
if (argc < 2) { printf ("usage: %s server_host\n", argv[0]); exit (1); } host = argv[1]; rpc_product_1 (host);exit (0);}
10/15/2009 37CSE 124 Networked Services Fall 2009
RPC_product_client.c (modified)/* * This is sample code generated by rpcgen. * These are only templates and you can use them * as a guideline for developing your own functions. */#include "RPC_product.h"voidrpc_product_1(char *host){ CLIENT *clnt; int *result_1; int product_1_arg1 = 8; int product_1_arg2 = 9;
#ifndef DEBUG clnt = clnt_create (host, RPC_product, RPC_product_interface, "udp"); if (clnt == NULL) { clnt_pcreateerror (host); exit (1); }#endif /* DEBUG */ result_1 = product_1(product_1_arg1, product_1_arg2, clnt); if (result_1 == (int *) NULL) { clnt_perror (clnt, "call failed"); }printf(“The product of %d and %d is %d\n”,product_1_arg1, product_1_arg2,
*result_1);
#ifndef DEBUG clnt_destroy (clnt);#endif /* DEBUG */}
intmain (int argc, char *argv[]){ char *host;
if (argc < 2) { printf ("usage: %s server_host\n", argv[0]); exit (1); } host = argv[1]; rpc_product_1 (host);exit (0);}
10/15/2009 38CSE 124 Networked Services Fall 2009
Run the client and serverMachine1: $ ./RPC_product_serverMachine2: $./RPC_product_client Machine1 The product of 8 and 9 is 72.
• Steps for this example RPC call – Create RPC_product.x– rpcgen RPC_product.x– modify the template server code– modify the template client code– make– run
10/15/2009 39CSE 124 Networked Services Fall 2009
SummaryWeek-3 Homework• Download the rtp_sample_trace.raw file that contains a sample
trace of two RTP sessions– Extract the RTP packets from the trace– Estimate the transit time and Jitter according to the algorithm
specified in RTP (RFC 3550)• Two ways you can achieve this: 1. Using WireShark directly to analyze the
traffic and 2. Using WireShark to convert the trace to a CSV file and write a simple program to estimate the transit time and jitter.
– Draw the Probability density function graph of the transit time and Jitter
– Compare the above graph with Probability density graph of well known distributions such as Normal, Poisson, and Exponential distributions assuming the same mean and variance as that of the trace sample
• Submission: Electronic copy by email • Deadline: 26th October 2009
10/15/2009 40CSE 124 Networked Services Fall 2009