CSE 124 Networked Services Fall 2009 B S

CSE 124 Networked Services Fall 2009 B. S. Manoj, Ph. D http: //cseweb. ucsd. edu/classes/fa 09/cse 124 Some of these slides are adapted from various sources/individuals including but not limited the slides from the text book by Peterson and Davie and IETF RFCs, IEEE/ACM digital libr Use of these slides other than for pedagogical purpose for CSE 124, may require explicit permissions from the respective sources. 10/15/2009 CSE 124 Networked Services Fall 2009 1

Announcements • Programming Assignment 1 – Due on 23 rd October • Week-2 Homework – Due on 15 th October • First Paper Discussion – Discussion on 29 th October – Write-up due on: 28 th October – Papers will be online soon 10/15/2009 CSE 124 Networked Services Fall 2009 2

Remote Procedure Call (RPC): An Application layer protocol for Distributed Computing 10/15/2009 CSE 124 Networked Services Fall 2009 3

Local and Remote Procedure Call In the local procedure call – The caller places arguments to a procedure in some wellspecified location – It then transfers control to the procedure – Eventually regains control – The results of the procedure are extracted from the wellspecified location – The caller continues execution 10/15/2009 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 process CSE 124 Networked Services Fall 2009 4

Procedure Call Remote Procedure Call Host A (Client) Client Program 0 x 45 0 x 46 0 x 47 0 x 48 proc() call proc() 0 x 545 0 x 546 0 x 547 0 x 548 call remote proc() 0 x 49 0 x 50 0 x 51 return 0 x 49 0 x 50 0 x 51 Client Program continues 10/15/2009 Host B (Server) proc() 0 x 545 0 x 546 0 x 547 0 x 548 return Client Program continues CSE 124 Networked Services Fall 2009 5

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 CSE 124 Networked Services Fall 2009 6

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 CSE 124 Networked Services Fall 2009 7

Local and Remote Procedure Call Local Procedure Call Remote Procedure call • Most often the procedures are within the same process • Always the processes are part of different processes • Between the Caller and called processes • Between the caller and called processes – there is a hardware bus or memory • Computing architecture – Homogeneous 10/15/2009 • Computing architectures – Heterogeneous • Data representation formats – Homogeneous – There is a complex network • Data representation formats – Heterogeneous CSE 124 Networked Services Fall 2009 8

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 CSE 124 Networked Services Fall 2009 9

An RPC activity flow Host B Host A Caller Process (Client) Called Process (Server) Return Arguments Client Stub Request Return Server Stub Request Reply RPC protocol The Internet 10/15/2009 CSE 124 Networked Services Fall 2009 10

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 CSE 124 Networked Services Fall 2009 11

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 CSE 124 Networked Services Fall 2009 12

RPC Stub compiler (rpcgen) 10/15/2009 CSE 124 Networked Services Fall 2009 13

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 10/15/2009 • • • Is considered an application layer protocol Runs over UDP (mostly) Reliability is ensured Remote processes identified CSE 124 Networked Services Fall 2009 Identifies Request-Reply matches 14

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 10/15/2009 – Directory name and file name – File name (base name) must be unique within the directory CSE 124 Networked Services Fall 2009 15

Matching Replys to Requests Client • 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 Crash Reboot Client Crash Reboot Req(0) Rep(0) Req(0, b. ID=0) Server Discards Req(0) Server Rep(0, b. ID=0) Req(0, b. ID=1) Rep(0, b. ID=1) 10/15/2009 CSE 124 Networked Services Fall 2009 Server replies Req(0, 1) 16

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 10/15/2009 • To avoid performance dent by implicit CSE 124 Networked Services Fall. ACK 2009 – Channel abstraction is used 17

RPC protocol challenges (contd) • 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 10/15/2009 CSE 124 Networked Services Fall 2009 18

RPC protocol challenges • 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 10/15/2009 CSE 124 Networked Services Fall 2009 19

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) 10/15/2009 CSE 124 Networked Services Fall 2009 20

Popular RPC implementations • Sun. RPC – 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 CSE 124 Networked Services Fall 2009 21

A brief comparison Sun. RPC DCE-RPC • Runs over UDP • Two tier addressing • End-point mapping service • Does not implement At. Most-Once semantics • Implements At-Most-Once semantics • Provides fragmentation and reassembly • Selective ACK scheme 10/15/2009 CSE 124 Networked Services Fall 2009 22

Sun. RPC • Addressing – Two-tier addressing • program number (32 bits) • procedure number (32 bits) • An NSF server may have – Program number: 0 x 00100003 – Procedure 1: read(), Procedure-2: write(), Procedure-3: setattr() – Each program is reachable by a UDP port • Sun. RPC picks up messages from the respective UDP port and call appropriate procedures – A port-mapper program maps programs to UDP ports 10/15/2009 • Port-mapper has a well known port number (111) and program number (0 x 00100000) • Port-mapper supports program-to-port-number mapping procedure (procedure no. 3)CSE 124 Networked Services Fall 2009 23

Sun. RPC 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 Sun. RPC client sends a Request with Procedure-6 to the new port number 10/15/2009 CSE 124 Networked Services Fall 2009 24

Sun. RPC Message Formats 31 0 XID Msg. Type=CALL RPCVersion=2 0 31 XID Program Version Procedure Msg. Type=REPLY Status=ACCEPTED Data Credentials (Variable) Verifier (Variable) Data Reply Data 10/15/2009 Request CSE 124 Networked Services Fall 2009 25

DCE-RPC Client Req Server Client Server Req Client Resp Req Server Ping Crash Ack Client Req Server Working Ping Working Request Response Reject Ping Working No. Call Quit Qu. ACK Resp Ack 10/15/2009 CSE 124 Networked Services Fall 2009 26

Fragmentation and Reassembly in DCE-RPC 10/15/2009 CSE 124 Networked Services Fall 2009 27

An example Non-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 10/15/2009 Networked Services Fall 2009 Result of multiplying. CSE 8124 and 9 is 72. 28

Distributed example RPC_product. x Program RPC_product { version RPC_product { int product(int, int) = 1; }=1 } = 0 x 200989123; Program number is defined by the user. Use range 0 x 20000000 to 0 x 3 fffffff. $rpcgen –N –a RPC_product. x $ls $Makefile. RPC_product. h RPC_product. x RPC_product_client. c RPC_product_server. c RPC_product. x~ RPC_product_clnt. c RPC_product_svc. c 10/15/2009 RPC_product_xdr. c CSE 124 Networked Services Fall 2009 29

Makefile $ mv Makefile. RPC_product Makefile $ make cc -g -c -o RPC_product_clnt. c cc -g -c -o RPC_product_client. c cc -g -c -o RPC_product_xdr. c cc -g -o RPC_product_client RPC_product_clnt. o RPC_product_client. o RPC_product_xdr. o -lnsl cc -g -c -o RPC_product_svc. c cc -g -c -o RPC_product_server. c cc -g -o RPC_product_server RPC_product_svc. o RPC_product_server. o RPC_product_xdr. o –lnsl 10/15/2009 CSE 124 Networked Services Fall 2009 30

Binary files $ ls –l -rw-r--r-- 1 root 1178 Oct 15 11: 53 Makefile -rwxr-xr-x 1 root 19424 Oct 15 11: 57 RPC_product_client -rw-r--r-- 1 root 833 Oct 15 11: 53 RPC_product_client. c -rw-r--r-- 1 root 8088 Oct 15 11: 57 RPC_product_client. o -rw-r--r-- 1 root 625 Oct 15 11: 53 RPC_product_clnt. c -rw-r--r-- 1 root 7504 Oct 15 11: 57 RPC_product_clnt. o -rw-r--r-- 1 root 1054 Oct 15 11: 53 RPC_product. h -rwxr-xr-x 1 root 23105 Oct 15 11: 57 RPC_product_server -rw-r--r-- 1 root 325 Oct 15 11: 53 RPC_product_server. c -rw-r--r-- 1 root 7144 Oct 15 11: 57 RPC_product_server. o -rw-r--r-- 1 root 2381 Oct 15 11: 53 RPC_product_svc. c -rw-r--r-- 1 root 11792 Oct 15 11: 57 RPC_product_svc. o -rw-r--r-- 1 root 101 Oct 15 11: 52 RPC_product. x -rw-r--r-- 1 root 100 Oct 15 11: 51 RPC_product. x~ -rw-r--r-- 1 root 293 Oct 15 11: 53 RPC_product_xdr. c -rw-r--r-- 1 root 4968 Oct 15 11: 57 RPC_product_xdr. o 10/15/2009 CSE 124 Networked Services Fall 2009 31

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 __cplus extern "C" { #endif struct product_1_argument { int arg 1; int arg 2; }; typedef struct product_1_argument; #define RPC_product 0 x 20091015001 10/15/2009 CSE 124 Networked Services Fall 2009 32

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 arg 1, int arg 2, CLIENT *clnt) { product_1_argument arg; static int clnt_res; memset((char *)&clnt_res, 0, sizeof(clnt_res)); arg 1 = arg 1; arg 2 = arg 2; 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 CSE 124 Networked Services Fall 2009 33

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 arg 1, int arg 2, struct svc_req *rqstp) { static int result; } /* * insert server code here */ result = arg 1 * arg 2; return &result; 10/15/2009 CSE 124 Networked Services Fall 2009 34

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 * CSE 124 Networked Services Fall 2009 _product_1 (product_1_argument *argp, struct svc_req *rqstp) 10/15/2009 35

Other files (RPC_product_xdr. c) /* * Please do not edit this file. * It was generated using rpcgen. */ #include "RPC_product. h" bool_t xdr_product_1_argument (XDR *xdrs, product_1_argument *objp) { if (!xdr_int (xdrs, &objp->arg 1)) return FALSE; if (!xdr_int (xdrs, &objp->arg 2)) return FALSE; return TRUE; } 10/15/2009 CSE 124 Networked Services Fall 2009 36

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" void rpc_product_1(char *host) { CLIENT *clnt; int *result_1; int product_1_arg 2; int main (int argc, char *argv[]) { char *host; if (argc < 2) { printf ("usage: %s server_hostn", argv[0]); exit (1); } host = argv[1]; rpc_product_1 (host); exit (0); } #ifndef DEBUG clnt = clnt_create (host, RPC_product_interface, "udp"); if (clnt == NULL) { clnt_pcreateerror (host); exit (1); } #endif /* DEBUG */ result_1 = product_1(product_1_arg 1, product_1_arg 2, clnt); if (result_1 == (int *) NULL) { clnt_perror (clnt, "call failed"); } #ifndef DEBUG clnt_destroy (clnt); 10/15/2009 CSE 124 Networked Services Fall 2009 #endif /* DEBUG */ 37

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" void rpc_product_1(char *host) { CLIENT *clnt; int *result_1; int product_1_arg 1 = 8; int product_1_arg 2 = 9; int main (int argc, char *argv[]) { char *host; if (argc < 2) { printf ("usage: %s server_hostn", argv[0]); exit (1); } host = argv[1]; rpc_product_1 (host); exit (0); } #ifndef DEBUG clnt = clnt_create (host, RPC_product_interface, "udp"); if (clnt == NULL) { clnt_pcreateerror (host); exit (1); } #endif /* DEBUG */ result_1 = product_1(product_1_arg 1, product_1_arg 2, clnt); if (result_1 == (int *) NULL) { clnt_perror (clnt, "call failed"); } printf(“The product of %d and %d is %dn”, product_1_arg 1, product_1_arg 2, *result_1); 10/15/2009 #ifndef DEBUG CSE 124 Networked Services Fall 2009 38

Run the client and server Machine 1: $. /RPC_product_server Machine 2: $. /RPC_product_client Machine 1 The product of 8 and 9 is 72. • Steps for this example RPC call – – – 10/15/2009 Create RPC_product. x rpcgen RPC_product. x modify the template server code modify the template client code make run CSE 124 Networked Services Fall 2009 39

Summary Week-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 Wire. Shark directly to analyze the traffic and 2. Using Wire. Shark 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: 26 th October 2009 10/15/2009 CSE 124 Networked Services Fall 2009 40