1 / 40

CSE 124 Networked Services Fall 2009

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.

regina
Download Presentation

CSE 124 Networked Services Fall 2009

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSE 124 Networked ServicesFall 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. Use of these slides other than for pedagogical purpose for CSE 124, may require explicit permissions from the respective sources. CSE 124 Networked Services Fall 2009

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

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

  4. Local and Remote Procedure Call In the local procedure call 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 • 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 CSE 124 Networked Services Fall 2009

  5. Remote Procedure Call Procedure Call Host B (Server) Host A Host A (Client) Client Program Client Program 0x45 0x46 0x47 0x48 0x49 0x50 0x51 0x45 0x46 0x47 0x48 0x49 0x50 0x51 proc() proc() call remote proc() call proc() 0x545 0x546 0x547 0x548 0x545 0x546 0x547 0x548 return return Client Program continues Client Program continues CSE 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 CSE 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 CSE 124 Networked Services Fall 2009

  8. Local and Remote Procedure Call Local Procedure Call 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 • 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 CSE 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 CSE 124 Networked Services Fall 2009

  10. An RPC activity flow Host B Host A Caller Process (Client) Called Process (Server) Return Arguments Arguments Return Client Stub Server Stub Request Reply Request Reply RPC protocol RPC protocol The Internet CSE 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 CSE 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 CSE 124 Networked Services Fall 2009

  13. RPC Stub compiler (rpcgen) CSE 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 CSE 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 CSE 124 Networked Services Fall 2009

  16. Matching Replys to Requests Server Client Req(0) • 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 Rep(0) Crash Reboot Req(0) Server Discards Req(0) Server Client Req(0, bID=0) Rep(0,bID=0) Crash Reboot Req(0, bID=1) Server replies Req(0, 1) Rep(0, bID=1) CSE 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 ofReq/Resp messages • Performance can be affected • To avoid performance dent by implicit ACK • Channel abstraction is used CSE 124 Networked Services Fall 2009

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

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

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

  22. A brief comparison SunRPC DCE-RPC Runs over UDP Two tier addressing End-point mapping service Implements At-Most-Once semantics Provides fragmentation and reassembly Selective ACK scheme • Runs over UDP • Two tier addressing • End-point mapping service • Does not implement At-Most-Once semantics CSE 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) CSE 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 CSE 124 Networked Services Fall 2009

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

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

  27. Fragmentation and Reassembly in DCE-RPC CSE 124 Networked Services Fall 2009

  28. An example Non-RPC-program.c #include <stdio.h> int product(int x, int y) { return x*y;} int main( intargc, 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. CSE 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. CSE 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_clientRPC_product_clnt.oRPC_product_client.oRPC_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_serverRPC_product_svc.oRPC_product_server.oRPC_product_xdr.o –lnsl CSE 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 CSE 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 <rpc/rpc.h> #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 CSE 124 Networked Services Fall 2009

  33. 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); } CSE 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, structsvc_req *rqstp) { static int result; /* * insert server code here */ result = arg1 * arg2; return &result; } CSE 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 <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 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 */ } CSE 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; } CSE 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); } CSE 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); } CSE 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 CSE 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: 26th October 2009 CSE 124 Networked Services Fall 2009

More Related