Project 1 -- Forking processes



CS-4513 Distributed Systems WPI, D-Term 2008

Hugh C. Lauer Project 1 (20 points)

Assigned: Friday, March 14, 2008 Due: Friday, March 28, 2008 at 6:00 PM

Introduction

This project is intended to introduce you to the practicalities of Remote Procedure Call. You will implement a program that functions like doit, the first project in many operating system courses, but that has remote action. You will develop a simple server and client, and you will create a Remote Procedure Call interface between them. You will also register the server with the Linux portmapper and bind to client to the server.

Specification

A typical first OS course project is to write a program doit that takes another command as an argument, forks a process to execute that command, and prints statistics about that execution. In this project, the program will be called rpcdoit; instead of forking a process, it makes a remote procedure call to another system to execute the command. To do this, it needs an extra argument — i.e., the name or IP address of the system on which to execute the command. Another program running on that system, called doitservice, actually executes the command, gathers the statistics, and returns them to rpcdoit, which displays them. Naturally, doitservice must be capable of executing more than one command at the same time, including from different callers.

The command line for rpcdoit includes one argument identifying the server system, the name of the command to execute, and the arguments for that command. For example, executing the following command

% rpcdoit arcturus cat /etc/motd [1]

causes the client rpcdoit program to package up the cat /etc/motd command and send it to the server machine arcturus for execution. There, doitservice forks a process to invoke the cat command on the file /etc/motd. It waits for its child process to terminate and then collects the following statistics about the system resources used by that child:–

1. the elapsed “wall-clock” time from the server’s point of view for the command execution in milliseconds,

2. the amount of CPU time used (both user and system time) in milliseconds,

3. the number of times the process was preempted involuntarily (e.g., time quantum expired, preemption by higher priority process, etc.),

4. the number of times the process gave up the CPU voluntarily (e.g., waiting for an I/O or resource),

5. the number of page faults, and

6. the number of page faults that could be satisfied from the kernel’s internal cache (i.e., reclaimed pages).

These statistics are obtainable on any Linux system using the getrusage() function. The doitservice program collects them and returns them to the rpcdoit client to be printed on the standard output (usually the terminal window) following the output of the command itself. In addition, rpcdoit must record and print the wall clock time from its own point of view and print the difference between the server execution time and the total (round trip) execution time.

If rpcdoit cannot contact the service for any reason, it should print an error message.

Implementation

Your main tool for implementing this project is rpcgen, the stub compiler for Sun’s Open Network Computing (ONC) implementation of a Remote Procedure Call facility. There is a lot of documentation available for ONC in general, rpcgen in particular, and XDR, the eXternal Data Representation supported by ONC. The following links are useful:–







There are man pages and info pages installed in most Linux systems (including your virtual machines) for rpcgen, rpcinfo, xdr, and related topics.[2] rpcgen itself provides a number of tools and options, including templates of both the client and server programs.

The principal input to rpcgen is the interface definition, a file with the extension “.x”. This defines the functions, arguments and results of the interface between the client rpcdoit and the service doitservice. You should design this interface first. This particular project probably requires only one remotely callable function. Its arguments should be the usual argv array and argc count of the number of entries in the array. Its returns should include

• a structure with the execution statistics of the remotely invoked command,

• the return code, and

• the output (stdout, stderr) from the execution of the command.

To simplify things, you may return just the first three lines of the output from the remotely executed command. Your rpcdoit program should print the output from the remote command first, followed by the statistics.

Once you have defined your interface, compile it with rpcgen. You should get

• two stubs, one for the client side and one for the server side,

• two .h files, one for the client program (rpcdoit) and one for the server program (doitservice), and

• (optionally) two prototype programs, one for the client and one for the service.

You are now ready to write rpcdoit and doitservice. It is suggested that you use, or at least refer to, the prototypes provided by rpcgen. Note that doitservice will have to use the portmapper — i.e., the system facility that maps RPC ports to service programs. Likewise, rpcdoit will have to use clnt_create to find and bind to the appropriate port on the server system. To identify your program and distinguish it from all others, you need to choose a random program number; it is suggested that you use 0x3dxxxxxx, where the last six digits are the lower order digits of your WPI student ID number.

Note that the remote commands execute with the user identity and privileges of the user who invokes doitservice.

You should develop your project on your virtual machine, as provided in the Fossil Lab.[3]

Testing

Testing a distributed application is always harder than testing a single-system application. It helps to include an optional argument -verbose on both rpcdoit and doitservice. When this is supplied, it should print out the sequence of actions, each with a time stamp, so that you can see who calls what with which arguments and when. Therefore, the actual arguments of rpcdoit are:–

% rpcdoit [-verbose] {IP-addr|srvrName} command [cmd-args …]

The simplest testing can be carried out entirely on the system on which you are developing your programs. Execute

% doitservice [-verbose]

and let it register itself with the portmapper. In separate shell window on the same machine, invoke rpcdoit, providing the machine’s own name or IP address as the server system. Once you have this working for a single instance of rpcdoit, you should try multiple instances at the same time in multiple shell windows. Be sure to select a remote program that takes a long time to execute (or sleeps for a while during execution) so that you can see that concurrent calls to the doitservice work correctly.

Finally, you need to test your implementation across a network. In the Fossil lab, you may either

• set up more than one virtual machine, with one acting as server and the other(s) acting as client(s); or

• set up one virtual machine as the server and SSH to the Fossil Server, where you can execute rpcdoit, providing the IP address of your virtual machine as the server.

Note that each virtual machine appears on the network to be a separate, standalone piece of hardware, even if it is running on the same host workstation as another virtual machine. Also note virtual machines in the Fossil Lab do not have registered names in the Fossil naming domain. In particular, they have different IP addresses from their host machines.

The graders will test your program with multiple concurrent clients.

Individual and Class Project

This is both an individual project and a class project. It is an individual project in the sense that each student must write, test, and submit his or her own program, not a copy or paraphrase of anyone else’s program.

However, it is a class project in the sense that you should all learn the concepts and practicalities of ONC, rpcgen, and remote procedure calls together. Share your questions! If you have a question, ask your classmates, friends, or mentors. Use the class e-mail list to ask questions or clarify your understanding. Share your knowledge! Once you have found the answer to something or have gained a useful insight, share it with your classmates via the class e-mail list.

Submission of Assignment

Submit your assignment for grading as directed in class. We will use the web-based Turnin tool developed by Professor Fisler’s group. A brief introduction can be found at



and access to the turnin system itself can be found at



For purposes of Turnin, this assignment is Project 1. Your submission should include

1. A write-up explaining your project and anything that you feel the instructor should know when grading the project. In particular, explain how you tested you programs. Write-ups in MS Word or PDF format are strongly preferred.

2. All of the files containing the code for this assignment. This includes the .x file for your interface, the .h files generated by rpcgen, and your programs for rpcdoit and doitservice. (You don’t need to include any of the other files generated by rpcgen, since these can be regenerated by make.)

3. One file called Makefile that can be used by the make command for building the entire system. It should support the “make clean” command, “make all” and make the rpcdoit and doitservice programs individually.

4. The test files or input that you use to convince yourself (and others) that your programs actually work and the output from your tests.

Do not put separate parts of the assignment in separate folders or specify separate Makefiles for them. Do not zip everything together into a zip file. Be sure to put your name at the top of every file you submit!

Grading Rubric

Points will be assigned as follows:–

• Five points for a complete, appropriate interface (.x) file.

• One point each for compiling your .c files for rpcdoit and doitservice without warnings.

• One point each (maximum of three) for correctly executing your test cases on a combined client-server system.

• Three points for correctly executing the graders’ test cases on a remote service

• Five points for correctly executing concurrent test cases from separate client systems (up to five) on your doitservice.

• Two points for a write-up. It is strongly preferred that this be in MS Word or PDF format.

If your Makefile does not generate working programs for this assignment, your submission will not be graded. However, the graders will attempt to get in touch with you by e-mail to fix the problem at a cost 10% per day.

Extra credit (5 points)

For five points extra credit, figure out how to transmit the entire output of the remote command back to the rpcdoit and implement it. This should effectively pipe the stdout of the remote command to the stdout of rpcdoit, and likewise with stderr. Thus, for example, a user should be able to execute

% rpcdoit arcturus ls /usr/share/doc

and get a very long list of files in the /usr/share/doc directory of the server arcturus.

-----------------------

[1] rpcdoit also takes an optional argument -verbose, which precedes the server name or address. See below for further details.

[2] All of these man pages refer to something called the RPC Programmming Manual, but the professor has not been able to locate a copy of this document in local Linux systems.

[3] The RPC facilities needed for the project are available on most Linux systems, including the CCC machines. However, there are inevitable differences in compilers that cause warnings or errors on one system but not another. Therefore, if there are any differences, the virtual machines in the Fossil Lab prevail.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download