Distributed Program Generation(rpcgen Example) Chuan-Ming liu CSIE NTUT Spring 04, TAIWAN
1 Distributed Program Generation (rpcgen Example) Chuan-Ming Liu CSIE, NTUT Spring ’04, TAIWAN
Introduction )Presents the sequence of steps a programmer takes to first create a conventional program and then divide the program into local and remote components O Uses an example application to show the output from rpcgen and additional code required to create the client and server components of a distributed program that uses rpc
2 Introduction Presents the sequence of steps a programmer takes to first create a conventional program and then divide the program into local and remote components Uses an example application to show the output from rpcgen and additional code required to create the client and server components of a distributed program that uses RPC
An Example to Illustrate Rpcgen D An example will clarify how rpcgen works and will illustrate most of the details )To explain how rpcgen works, we have selected an extremely simple application
3 An Example to Illustrate Rpcgen An example will clarify how rpcgen works and will illustrate most of the details To explain how rpcgen works, we have selected an extremely simple application
Dictionary operations D Consider an application that implements a simple database that offer 4 basic operations: initialize, insert, delete, and lookup ASsume that input to the application is a text file. where each line contains a one letter command followed by a word DFig. 23. 1 lists the commands, and gives the meaning of each
4 Dictionary Operations Consider an application that implements a simple database that offer 4 basic operations: initialize, insert, delete, and lookup Assume that input to the application is a text file, where each line contains a oneletter command followed by a word Fig. 23.1 lists the commands, and gives the meaning of each
Steps to Distributed Application )Fig.22.6 1. Build a conventional application 22. Divide the program into two parts 03. Create an rpcgen specification 24. Run rpcgen to generate 4 source code files 05. Write stub interface procedures 26. Compile and link the client program 27. Compile and link the server program D 8. Start the server and execute the client
6 Steps to Distributed Application Fig. 22.6 1. Build a conventional application 2. Divide the program into two parts 3. Create an rpcgen specification 4. Run rpcgen to generate 4 source code files 5. Write stub interface procedures 6. Compile and link the client program 7. Compile and link the server program 8. Start the server and execute the client
Step 1: Build a Conventional Application Program DAn application program(dict. c) for the dictionary problem written in C )To produce an executable binary for the application, the programmer invokes the C compiler to produce an executable file named dict Dcc -o dict dict. c
8 Step 1: Build a Conventional Application Program An application program (dict.c) for the dictionary problem written in C To produce an executable binary for the application, the programmer invokes the C compiler to produce an executable file named dict: cc –o dict dict.c
Step 2: Divide the Program into Two Parts DFig 23.2 shows the procedure call graph for the original conventional programs that solves the dictionary problem DA call graph represents a program's procedural organizations D When considering which procedures can be moved to a remote machine the programmer must consider the facilities that each procedure needs
9 Step 2: Divide the Program into Two Parts Fig. 23.2 shows the procedure call graph for the original, conventional programs that solves the dictionary problem A call graph represents a program’s procedural organizations When considering which procedures can be moved to a remote machine, the programmer must consider the facilities that each procedure needs
Step 2: Divide the Program into Two Parts(cont) otherwise access file descriptors cannot be D Procedures that perform 1/0, e.g., nestin moved to a remote machine easil D Procedures should execute on the same machine as the data they access passing large data structures as arguments to remote procedures is inefficient THus, procedures initw, insert, delete and lookup belong on the same machine as the dictionary itself
11 Step 2: Divide the Program into Two Parts (cont.) Procedures that perform I/O, e.g., nextin, or otherwise access file descriptors cannot be moved to a remote machine easily Procedures should execute on the same machine as the data they access; passing large data structures as arguments to remote procedures is inefficient Thus, procedures initw, insertw, deletew, and lookup belong on the same machine as the dictionary itself
Step 2: Divide the Program into Two Parts(cont) )Fig. 23. 3 illustrates the new structure of the dictionary application with the data for the dictionary and access procedures moved to a remote machine OThe programmer must consider the arguments that each remote procedure will require along with the cost of passing that information across a network OThe diagram helps the programmer assess how network delays will affect program performance
12 Step 2: Divide the Program into Two Parts (cont.) Fig. 23.3 illustrates the new structure of the dictionary application with the data for the dictionary and access procedures moved to a remote machine The programmer must consider the arguments that each remote procedure will require along with the cost of passing that information across a network The diagram helps the programmer assess how network delays will affect program performance
Step 2: Divide the Program into Two Parts(cont) )The compiler checks for problems like symbolic constant referenced by both parts and the linker checks to see that all data structures have been collected together with the procedures that reference them D Catching such problems early (i. e, before additional code has been inserted) makes them easier to repair 15
15 Step 2: Divide the Program into Two Parts (cont.) The compiler checks for problems like symbolic constant referenced by both parts, and the linker checks to see that all data structures have been collected together with the procedures that reference them Catching such problems early (i.e., before additional code has been inserted) makes them easier to repair