ࡱ> fhe%` 7bjbjٕ .`G-k%@@@8xt, 2f$^"1<m 1111111$q3h5111%%%1%1%%R-/ 0!A@#*/110 2,/f6$6</6/% X11y%^ 2d << 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  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: the elapsed wall-clock time from the servers point of view for the command execution in milliseconds, the amount of CPU time used (both user and system time) in milliseconds, the number of times the process was preempted involuntarily (e.g., time quantum expired, preemption by higher priority process, etc.), the number of times the process gave up the CPU voluntarily (e.g., waiting for an I/O or resource), the number of page faults, and the number of page faults that could be satisfied from the kernels 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 Suns 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:  HYPERLINK "http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-Q0R5B-TET1_html/TITLE.html" http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-Q0R5B-TET1_html/TITLE.html  HYPERLINK "http://web.cs.wpi.edu/~rek/DCS/D04/SunRPC.html" http://web.cs.wpi.edu/~rek/DCS/D04/SunRPC.html  HYPERLINK "http://web.cs.wpi.edu/~cs4513/b05/week4-sunrpc.pdf" http://web.cs.wpi.edu/~cs4513/b05/week4-sunrpc.pdf There are man pages and info pages installed in most Linux systems (including your virtual machines) for rpcgen, rpcinfo, xdr, and related topics. 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. 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 machines 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 elses 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 Fislers group. A brief introduction can be found at HYPERLINK http://web.cs.wpi.edu/~kfisler/turnin.html http://web.cs.wpi.edu/~kfisler/turnin.html and access to the turnin system itself can be found at HYPERLINK http://turnin.cs.wpi.edu:8088/servlets/turnin.ss http://turnin.cs.wpi.edu:8088/servlets/turnin.ss For purposes of Turnin, this assignment is Project 1. Your submission should include 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. 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 dont need to include any of the other files generated by rpcgen, since these can be regenerated by make.) 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. 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.  rpcdoit also takes an optional argument -verbose, which precedes the server name or address. See below for further details.  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.  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.     PAGE  PAGE 5 !")+,FHO[kqw}1 5 ] ^ ) 3 T V c d m     ! M Q T hCPhCP5CJOJQJhCP5CJOJQJ hCPNHhlhF`hDs5CJOJQJhCP hhDs h3x NHh3x h3x 5CJOJQJh Qhy}hi.hhJ{Gh5hDsh3x h/>7V d W B S>]Vgd|x^gd*5gd-gd\gdJ{GgdHKgd\gd !gdG577T c n  V W l s !()2?@ABT[\ov°ڗڗڐ~zhZhChCPhC5CJOJQJ h\hDshZhKG5CJOJQJhCP5CJOJQJ"jhh0J5CJOJQJUhhhh5CJOJQJ hDsNHhDshKG h`I@NHh`I@hCPhCP5CJOJQJ hCPNHhCP/EF\fqv '+!,-4<=>N[bν¹ʹΣΣΊhCP5CJOJQJhCPhC5CJOJQJhUKehZhZ5CJOJQJhj!h\ hKG6hJ{GhhhhKG h\h\hCh`I@hj!hDs5CJOJQJ h\hDshZ hZNH6$)27<06QSjpz|}UVW̷̯̯̯̯̯̾̾̈}h*5h*5CJaJjh*5h*5CJUaJhh hhNHh*5h*55CJOJQJh*5h- h`I@hCh_kh_k5CJOJQJh_khl h`I@NH h`I@6 hC6 hKG6h`I@hCP5CJOJQJhKGhC.&TVWX"ioqxz}ɽɲɠɽɲɁɲ}y}k}k}kyayjh*50JUh*5h*55CJOJQJhkh*5#j:hPKh*5CJUaJhPKh*50JCJaJ#jhPKh*5CJUaJh*5h*5CJaJjh*5CJUaJh*5CJaJh*5h*50JCJaJjh*5h*5CJUaJ#jh*5h*5CJUaJ#$,5]_|!"vz>DFL!"I ,/0789h|xh|x5CJNHOJQJ h NHh h 5CJOJQJh h|xh|x5CJOJQJh|xhCPhk5CJOJQJ hk6hkhk5CJOJQJh`I@hh hkNHhkh*5hk5CJOJQJ22rJ>Z:!w!!"#^$$m%&'5'gdgd gd gdHj9gd(gdgd\gd|xgd|xgd`I@9:=>$/EOKMXZ A I R Y ^ ۿ۹ۿ۫۹ۧ}yۿhjhH 0JUht&ht&5CJOJQJht&hHK hfNHhH hfhfhf5CJOJQJ hWNHhWhW5CJOJQJh|xhW5CJOJQJhWhHj9h|xh|x5CJOJQJh|xhh hhhh/^ i ! !!!,!3!9!:!*B*CJOJQJ^JaJph/jhEhCJOJQJU^JaJhCJOJQJ^JaJ#jhCJOJQJU^JaJ hh h5h5CJNHOJQJh5CJOJQJh,,,,--+->-@-^-`-t-z-------.....+.3.4.L.P.j.w.................?/@/]/c/l/m/r/w/z//hyE` h# /NHh7hSh75CJOJQJhy}hyE`h# /5CJOJQJ h# /6h(h# /5CJOJQJhj!h# /6 h-h# /hShS5CJOJQJhSh(h# /hqhy&8/////// 0 0I0J0~0000000000000000011111/14111111?2J2L2m22222~x hNH h6h ht&NHht&ht&ht&5CJOJQJht&hqN5CJOJQJhqNh(hqhyE`h# /6hmU2hyE`6hyE` h# /6h# /hh# /5CJNHOJQJhh# /5CJOJQJhq5CJOJQJ/2222222223/303]3333344C4I4g4m4q4x444445$5=5E5F5G5H5J5Q5r5z55556u6v6w6667ؼؼؼؼؼؼص h=NH h*5h= h=6#hhh=5CJOJQJ^JaJh=jh=0JU hqhJ hJ hJ 5CJOJQJhJ ht&5CJOJQJhJ h7 h?xhNHh?xhht&hqhq5CJOJQJhq13344G55v677777777777777777 &`#$gdCRgdH gdkgdhgdJ gdJ gdqgdt&7777777777777777777777777 hqhJ h0JmHnHuh= h=0Jjh=0JUjhe Uhe hH h=677gdJ ,1h/ =!"#$% DyK Yhttp://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-Q0R5B-TET1_html/TITLE.htmlyK http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-Q0R5B-TET1_html/TITLE.htmlyX;H,]ą'cIDyK /http://web.cs.wpi.edu/~rek/DCS/D04/SunRPC.htmlyK vhttp://web.cs.wpi.edu/~rek/DCS/D04/SunRPC.htmlyX;H,]ą'cYDyK 3http://web.cs.wpi.edu/~cs4513/b05/week4-sunrpc.pdfyK ~http://web.cs.wpi.edu/~cs4513/b05/week4-sunrpc.pdfyX;H,]ą'cDyK yK nhttp://web.cs.wpi.edu/~kfisler/turnin.htmlyX;H,]ą'cDyK yK zhttp://turnin.cs.wpi.edu:8088/servlets/turnin.ssyX;H,]ą'cN@N jNormaldh CJOJQJ_HaJmH sH tH V@V _k Heading 1 $@&5CJ KH OJQJ\^JaJ J@J Ds Heading 4$<@&5CJ\aJDA@D Default Paragraph FontRiR  Table Normal4 l4a (k(No ListDB@D _k Body Textd,<xOJQJTOT G code fragmenthd^h5CJOJQJP:@P * List Number 2 & Fd,xOJQJ>1@"> \ List Number  & F<>;@2> \ List Number 3  & FZYBZ  Document Map-D M CJOJQJ^JaJP6@RP * List Bullet 2 & Fd,xOJQJ>0@b> - List Bullet  & Fx4 @r4 "8Footer  !.)@. "8 Page Number4U@4 {d Hyperlink >*phFV@F {dFollowedHyperlink >*B* phF@F *5 Footnote TextCJOJQJaJ@&@@  QFootnote ReferenceH*FOF kFootnotehd(^h`4@4  Header  !@//jm/`VdWB S> ] V 2rJ>Z:w^m5 !""#J##$$&&t'J(Y(~(()))L**++,,G--v./////////////////00000V0V0V0V 0V 0V 0V 0V 0V 0V0V0V00 0 0 0 0 0  0  0  0 0 0  0  0  0 0 0 0 0000000 0 00000000!0!0!0!0! 0! 0! 0! 0!0!00J( 0J( 0 J( 0 J( 0 J( 0 000000@0@0@000j@0H00@0H00@0H00@0H00@0@0@0@0@0@0H00-VdWB S> ] V 2rJw^m5 !""#J##$$&&*++,/0 00 00o0o0o0o 0o 0o 0o 0o 0o 0o0o0o 00 0 0 0 0 0  0  0  0 0 0  0  0 0  0000 0 000 000 000000 0 0 0J0304J030J03000 $$$'T 9^ #*,/277 !"#%&')*+,.5'377$(-/7V W""#K###/XXXXX  '!!8@0(  B S  ? OLE_LINK3 _Hlt177013877 _Hlt177013878 _Hlt177013925 _Hlt177013926 OLE_LINK1 OLE_LINK2 # ###%%/@@@@? # ###%%/\ d -/:/>*urn:schemas-microsoft-com:office:smarttags PersonName lL15)3MTcnls!()1;?T[  ! , [ b 0 6   ioqxz}$vz>DFL ,7$/EOMXRY^i,3<CS`ks'1ho$+ V"\"y""%#+###t%z%%%%%%%+&3&&&&&''((()?*J***,,C,I,g,m,q,x,,,,,,,,,,,--=-E-G-J-Q-..//////////////OP)1BHSV] `   25?I##8'<')),,,,G-J-Q-//////////////33333333333333333Vd2 J(X(++G---//////////////G-////////////// |r`Rm}`Į~n%N, r;nFDxHx<Y]28"Yu^`.^`.88^8`.h^`. ^`OJQJo( ^`OJQJo( 88^8`OJQJo( ^`OJQJo(hh^h`. hh^h`OJQJo(h^`.h^`.hpLp^p`L.h@ @ ^@ `.h^`.hL^`L.h^`.h^`.hPLP^P`L.h^`.h ^`hH.h pLp^p`LhH.h @ @ ^@ `hH.h ^`hH.h L^`LhH.h ^`hH.h ^`hH.h PLP^P`LhH. ~}|]8"YuH                   xwCP QnZa+,7#1 3x J e f~W GfO{.H e j!G!*|%(i.# /S2//8Q"9^.9Hj9' ;`I@~AgeB( FJ{G\0I4JHKN!RCR#t\3C^6_yE`F`]aK-dUKe?xhk=msDsHPs t ~wz|2p}y}qkUKc5"8S3hGPSJ\ :|xm^a:V@ %Ct&{'(= ZqN'}j*5y&hINT@****/P@UnknownGz Times New Roman5Symbol3& z Arial?5 z Courier New9Garamond5& zaTahoma"1hEbfkÆFkÆ&R&R#4d0-0-2QHX0Ds2Project 1 -- Forking processes$CS-502 Operating Systems (Fall 2006) Hugh C. Lauer Hugh C. Lauer<         Oh+'0$ <H h t   Project 1 -- Forking processes(CS-502 Operating Systems (Fall 2006)Hugh C. LauerNormalHugh C. Lauer14Microsoft Office Word@Sh@Lӂ,@A@~ A&՜.+,D՜.+,h$ hp   Worcester Polytechnic InstituteR0-' Project 1 -- Forking processes Title 8@ _PID_HLINKSA@  1http://turnin.cs.wpi.edu:8088/servlets/turnin.ss n# +http://web.cs.wpi.edu/~kfisler/turnin.html ba3http://web.cs.wpi.edu/~cs4513/b05/week4-sunrpc.pdf 9c/http://web.cs.wpi.edu/~rek/DCS/D04/SunRPC.html ):Yhttp://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-Q0R5B-TET1_html/TITLE.html   !"#$%&'()*+,-./02345678:;<=>?@ABCDEFGHIJKLMNOPQRSTVWXYZ[\^_`abcdgRoot Entry F0w&AiData 11Table96WordDocument.`SummaryInformation(UDocumentSummaryInformation8]CompObjq  FMicrosoft Office Word Document MSWordDocWord.Document.89q