1. CSE 124 Networked Services Fall 2009 B. S. Manoj, Ph.D http://cseweb.ucsd.edu/classes/fa09/cse124 10/15/20091CSE 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.

2. 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/20092CSE 124 Networked Services Fall 2009

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

4. 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 process 10/15/20094CSE 124 Networked Services Fall 2009

5. Host A Procedure Call 0x45 0x46 0x47 0x48 0x49 0x50 0x51 0x545 0x546 0x547 0x548 Client Program call proc() proc() return Client Program continues Host B (Server) Host A (Client) 0x45 0x46 0x47 0x48 0x49 0x50 0x51 0x545 0x546 0x547 0x548 Client Program call remote proc() proc() return Client Program continues Remote Procedure Call 10/15/20095CSE 124 Networked Services Fall 2009

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

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

8. 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/20098CSE 124 Networked Services Fall 2009

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

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

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

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

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

14. 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/200914CSE 124 Networked Services Fall 2009

15. 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/200915CSE 124 Networked Services Fall 2009

16. 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 Server Discards Req(0) Req(0, bID=0) Rep(0,bID=0) Crash Client Server Req(0, bID=1) Reboot Server replies Req(0, 1) Rep(0, bID=1) 10/15/200916CSE 124 Networked Services Fall 2009

17. 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/200917CSE 124 Networked Services Fall 2009

18. 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/200918CSE 124 Networked Services Fall 2009

19. 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/200919CSE 124 Networked Services Fall 2009

20. 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/200920CSE 124 Networked Services Fall 2009

21. 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/200921CSE 124 Networked Services Fall 2009

22. 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/200922CSE 124 Networked Services Fall 2009

23. 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/200923CSE 124 Networked Services Fall 2009

24. 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/200924CSE 124 Networked Services Fall 2009

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

26. DCE-RPC Req Resp Client Server Ack Crash Req Client Server Req Resp Client Server Ack Req Resp Client Server Ack Ping Working Ping Request Response Reject Ping Working NoCall Quit QuACK 10/15/200926CSE 124 Networked Services Fall 2009

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

28. An example Non-RPC-program.c #include 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/200928CSE 124 Networked Services Fall 2009

29. 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.x RPC_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/200929CSE 124 Networked Services Fall 2009

30. Makefile $ mv Makefile.RPC_product Makefile $ make cc -g -c -o RPC_product_clnt.o RPC_product_clnt.c cc -g -c -o RPC_product_client.o RPC_product_client.c cc -g -c -o RPC_product_xdr.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.o RPC_product_svc.c cc -g -c -o RPC_product_server.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/200930CSE 124 Networked Services Fall 2009

31. 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.o 10/15/200931CSE 124 Networked Services Fall 2009

32. 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 #ifdef __cplusplus extern "C" { #endif struct product_1_argument { int arg1; int arg2; }; typedef struct product_1_argument product_1_argument; #define RPC_product 0x20091015001 10/15/200932CSE 124 Networked Services Fall 2009

33. Client file (RPC_product_clnt.c) /* * Please do not edit this file. * It was generated using rpcgen. */ #include /* 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/200933CSE 124 Networked Services Fall 2009

34. 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/200934CSE 124 Networked Services Fall 2009

35. Other files (RPC_product_svc.c) /* * Please do not edit this file. * It was generated using rpcgen. */ #include "RPC_product.h" #include #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 void rpc_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; } int main (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_produc t_1, IPPROTO_UDP)) { fprintf (stderr, "%s", "unable to register (RPC_product, RPC_pro duct_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_produc t_1, IPPROTO_TCP)) { fprintf (stderr, "%s", "unable to register (RPC_product, RPC_pro duct_interface, tcp)."); exit(1); } svc_run (); fprintf (stderr, "%s", "svc_run returned"); exit (1); /* NOTREACHED */ } 10/15/200935CSE 124 Networked Services Fall 2009

36. 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->arg1)) return FALSE; if (!xdr_int (xdrs, &objp->arg2)) return FALSE; return TRUE; } 10/15/200936CSE 124 Networked Services Fall 2009

37. 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_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 */ } int main (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/200937CSE 124 Networked Services Fall 2009

38. 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_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 */ } int main (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/200938CSE 124 Networked Services Fall 2009

39. Run the client and server Machine1: $./RPC_product_server Machine2: $./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/200939CSE 124 Networked Services Fall 2009

40. 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 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: 26 th October 2009 10/15/200940CSE 124 Networked Services Fall 2009