cse 124 networked services fall 2009 b. s. manoj, ph.d 10/15/20091cse 124 networked services fall...

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


Remote Procedure Call (RPC): An Application layer protocol for

Distributed Computing


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


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


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


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


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


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


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


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


RPC Stub compiler

(rpcgen)


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


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


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


• 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)


• 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


• 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


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


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


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


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


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


Fragmentation and Reassembly in DCE-RPC


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.


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


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


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);}


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


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 */}


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


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);}


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);}


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


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


cse 124 networked services fall 2009 b. s. manoj, ph.d 10/15/20091cse 124 networked services fall...

Documents

remote procedure calls

execution remote procedure

remote server

networked services

reply message

request message client

methods of remote objects

reply server