CSE 5306 Lab # 1 Fall – 2003



CSE 5306 Lab # 2 Fall – 2009

Online Advising Simulation using RPC & Message Queuing

Objective:

1. Exposure to application development in Distributed environment

2. Understanding two communication models for distributed processes

a. Remote Procedure Call (Synchronous Communication)

b. Message Oriented Communication (Asynchronous persistent Communication)

3. Understanding the message queuing systems.

Due: 5 November, 11:59:59 pm

Project Specification:

In this lab you will simulate an online advising system which is similar to what you might have used for registering your classes. Students request clearance for a course from the advisor. At some other time the advisor approves or disapproves the request and then the student is notified of the advisor’s decision. You will require 4 processes to simulate this: a student process, an advisor process, a notification process and a message queuing server (MQS). The student process, advisor process and notification process communicate through the message queuing server (message oriented middleware). Communication from these processes to the message queuing server is through remote procedure calls. Please see figure 1:

[pic]

Communication Model

Figure 1

Note: Student, Advisor and Notification Process do not communicate directly. The dotted arrow in figure 1 implies the logical flow of messages.

Student Process:

The Student process works on behalf of the student. It takes as input (from the command prompt) the name of the student and the course for which the student wants clearance. The Student process should then send a message through the MQS to the Advisor seeking clearance. It should keep doing this (under control of the user) until it is killed.

Advisor Process:

When it is started, the Advisor Process should contact the MQS for any message from the Student process. If there are any messages then it should retrieve them and approve or disapprove the requests based on a random probability. It should then send a message for each request (message) through the MQS to the Notification process so that it (the Notification process) can notify the Student process about the decision. If there are no messages for the Advisor process in the MQS then it should sleep for 3 seconds and again contact back to check for messages. It should keep doing this until is killed. You should also print out a message for each request (message) that the Advisor process processes (whether it is approved or not).

Notification Process:

The Notification process notifies the Student process about the Advisor’s decision. To simulate this you just have to print on the command prompt the student name, course and the advisor decision. The Notification process should check MQS for messages from the Advisor process. If there are any messages then it should retrieve them and notify the student by printing as stated above. If there are no messages then it should sleep for 7 seconds and then contact the MQS again. It should keep doing this until is killed.

Message Queuing Server (MQS):

This process simulates the Message Queuing server. MQS should have the following:

1. It should be able to store or return a message from or to any requesting process.

2. You should have only one physical queue (single array, linked list or queue, etc.) to store the messages from both Student and Advisor process.

3. Messages once retrieved should be physically deleted from the queue.

4. Messages should be persistent, i.e. even if you shut down the server the messages should not be lost. For that you should store the messages in a file. When the MQS is restarted it should reload all the messages from the file to your main memory data structure (array or linked-list etc). We will assume that the MQS will be killed only after all the 3 other processes are killed so that you don’t need to worry about problems that would arise if it were killed while in communication.

RPC Specification:

The MQS should implement an interface which other 3 processes can use to store and retrieve message. For the “program number” in your RPC interface you should use a hexadecimal number in range of 0x20000000 – 0x3fffffff (other numbers are reserved). I would suggest you to use last four digit of your ID as the last four digits of the ‘program number’ with any prefix to avoid collisions. Ex: 0x31235678 if the last 4 digits of your id are 5678.

Other Specifications:

1. The MQS will be started first. The other 3 processes can be started or stopped in any order. So make sure that your application works fine independently of the order in which these 3 processes are started and stopped.

2. For the Advisor and Notification process, print a message (like “no message found”) on the console when it probes the MQS and there is no message.

3. You could use any programming language, Operating system, or Server to complete this lab. However, more support is provided if you use “C” language on either Omega (UNIX) or Gamma (Solaris) servers at UTA.

4. You can run multiple processes on the same server using multiple telnet sessions.

5. You can use either of the RPC facilities present at Omega (UNIX) and Gamma (Solaris) servers at UTA. Gamma seems to have a newer version of ‘rpcgen’ then Omega. You can even try running some processes on Omega and some on Gamma. Using Omega or Gamma is not mandatory.

6. If you use the Gamma machine then your server will run in background mode, you should kill the server using the following command after you are done:

rpcinfo –d prognum vernum

7. You can use the ‘rpcinfo –p’ command to know what ‘program numbers’ other services (using RPC) are using.

8. Use proper names for your interface, various programs and variables.

References:

1. (Tutorial on using Sun RPC and syntax information for the interface language (IDL)).

2. (Good Tutorial on Distributed Technologies including RPC).

3. (RPC with C).

4. (rpcgen).

5. (C Programming).

6. Also look at the manual pages of the following: rpcgen and rpc ($man rpcgen)

Writeup:

Your write-up should include instructions on how to compile and run your program. Ideally it should be complete enough that the TA can test your program without your being there. Your writeup should include any known bugs and limitations in your programs. If you made any assumptions such as limits on file sizes you should document what you decided and why. This writeup should be in text format and should be submitted along with your code. If you used any code that you found on the Internet or in a book then the write-up should give a reference to the source.

Submission Guidelines:

Please include a make file or a ‘run.sh’ file which has UNIX commands to compile all your *.c files and also include commands to make an executable for each of the process. Only submit the interface file (*.x) do not submit the file generated after using the ‘rpcgen’ command.

You will email your program source code to the class email TA, Mr. Derek White, at dwhite@uta.edu. You should tar & gz your source files, makefile (or run.sh) and writeup into a single file and email it. The name of the zip file should be your UNIX login ID. Be sure that you include everything necessary to unzip this file on another machine and compile and run it. This might include forms, modules, classes, config. files, etc. DO NOT INCLUDE ANY RUNNABLE EXECUTABLE (binary) program.

Make sure your name and your student ID are listed in your writeup, and in a comment in your source code. You may resubmit the project at any time. The submission time of the latest submission will be used for determining whether the assignment is on time or not. Late submissions will be accepted at a penalty of 10 points per day. This penalty will apply regardless of whether you have other excuses. In other words, it may pay you to submit this project early. If the TA can not run your program based on the information in your writeup then he will email you to schedule a demo. The TA may optionally decide to require all students to demonstrate their labs. In that case we will announce it to the class.

If your program is not working by the deadline, send it to the class account anyway and review it with the TA for partial credit. Do not take a zero on any lab just because the program isn't working yet. We will make an effort to grade you on the work you have done.

Grading:

Points - element

10 - Student Process works correctly

15 - Advisor Process works correctly

10 - Notification Process works correctly

10 - MQS stores and retrieves the messages correctly

10 - MQS deletes message after it is retrieved

15 - Messages in MQS are persistent

15 - Messages are stored in a single data structure

10 - Student, Advisor and Notification process work independently of each other

05 - Comments in code

To receive full credit for comments in the code you should have brief headers at the start of every module/ subroutine/ function explaining the inputs, outputs and function of the module. You should have a comment on every data item explaining what it is about. (Almost) every line of code should have a comment explaining what is going on. A comment such as /* Add 1 to counter */ will not be sufficient. The comment should explain what is being counted.

Deductions for failing to follow directions:

-2 Including absolute/ binary/ executable module in submission

-2 Submitting writeup in other than plain ASCII text format

-2 Submitted file has a name other than student's UNIX LoginId.gz

-5 Not submitting a make file or a run.sh file.

Important Note:

You may discuss the problem definition and tools with other students. You may discuss the lab requirements. You may discuss or share project designs. All coding work must be your own. You may use any book, WWW reference or other people’s programs (but not those of other students in the class) as a reference as long as you cite that reference in the comments. If you use parts of other programs YOU MUST CITE THOSE REFERENCES. If we detect that portions of your program match portions of any other student’s program it will be presumed that you have collaborated unless you both cite some other source for the code. You must not violate UTA, state of Texas or US laws or professional ethics. Any violations, however small, will not be tolerated. Students who do not submit anything get a grade of 0. Therefore students who break the rules will receive a negative grade – most likely a -50 on this lab assignment.

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

Message Queuing Server

Student Process

Notification Process

Advisor Process

RPC

RPC

RPC

MO

MO

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

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

Google Online Preview   Download