Assignment 2, CS-701, Fall 1997
Object Broker Project-- Use Case 4
Use Case 4 -- ob and om Communicate
Changes to om
Now we modify om so that it interacts with ob instead of
ou. Before entering the endless loop to receive requests,
om writes a "hello" request to ob. If ob does not
respond, om exits. Otherwise, it writes the hostname for
ob in a logfile message, such as "Communicating with object
broker running on jaguar."
Whenever om exits, it first writes a "good-bye" request to
ob.
Optional: Make om handle SIGINT the same
way as an "exit" request.
Except for sending "hello" and "good-bye" requests to ob,
om for this case is basically the same as it was for Use Case
2a. The one thing that changes is that om no longer binds its
socket to a particular port number. The kernel will assign a port
number when the socket is first written to (when om sends the
"hello" request), and the ob learns what that port number is
when it receives the "hello" request from om.
Changes to ob
Now ob maintains a list of currently active object managers.
This list is updated as ob receives "hello" and "good-bye"
requests from om programs. (You can also use ou to trick
ob because the present design of ou does not check what
the user types.)
When the user sends a "shutdown" request to ob, it sends "exit"
requests to all currently active om programs.
Here is a summary of how ob responds to requests for this use
case:
Request
Type
| Argument
List
| Return
Value
| Action
|
|---|
hello
| Anything
| "Hello acknowledged"
| Write a message to the log file that includes a unique name
for the program that sent the request. Add the unique name to a
list of "registered object managers."
|
good-bye
| Anything
| "Good-bye acknowledged"
| Remove the sender's unique name from the list of registered
object managers.
|
list
| Anything
| If the Argument list is the token, "managers," a string
containing the names of all registered object managers.
Otherwise, a string saying like the one returned for Use Case 3.
| Depends on the Argument List
|
shutdown
| Anything
| Nothing
| Send an "exit" request to each om on the list of
registered object managers. Write a message to the log file that
includes the Argument List as part of the message, then exit
ob.
|
There are three different changes you are making to ob for this
use case:
- Update the list of registered object managers in response to
"hello" and "good-bye" requests.
- Return the list of registered object managers in response to "list
managers" requests.
- Send "exit" requests to registered object managers in response to
"shutdown" requests.
I recommend that you implement and test each of these three changes
separately. If you try to do them all at once, it will be too hard to
debug problems that come up because there will be too much new code to
keep track of. Initially, the list can be just a list of names, and
you can examine it using gdb or ddd as ob runs.
Then you can implement the "list managers" request. Finally, augment
the list so that it has both the name and sockaddr_in
struct for each manager, and use the sockaddr_in struct
for sending "exit" requests to the registered managers.
Testing
It's important to test your programs carefully. There are three types
of conditions you need to test, and your should test them in the order
listed here: (1) Normal input. Assume all three programs and the user
behave as expected, and be sure they interact properly. (2) Boundary
conditions. Check that the programs work correctly when inputs on
internal conditions are an the ends of their allowable range. For
example, what if the use asks for the list of managers when the list is
empty? What happens if all the managers send "good-bye" requests, and
then a new manager sends another "hello" request? (3) Error
conditions. What if the user enters an invalid request type, or too few
or too many arguments on the command line? What if the ob
receives a "good-bye" request from a program that is not on the list of
registered object managers?
Concentrate your effort on testing on the boundary conditions to
be sure your programs are as robust as possible.
Testing ob's List Management
There is a logical problem in testing this use case. There is no way to
cause an om to exit except by shutting down the ob, which
means there is no way to be sure that ob manages deletions from
its list of managers correctly. You can't use ou to send a
good-bye message on behalf of a manager because each invocation of
ou gets a different port number, so there is no way to generate
the same unique host:port combination that ob uses to identify
managers.
You can use ~vickery/bin/om_4 to do this test in either of two
ways. First, my om_4 implements the feature of sending a
"good-bye" message when it receives a SIGINT. Also, if you set the
environment variable OM_TIMEOUT to a non-zero numerical
value, the program will exit any time it waits that many seconds
without receiving any datagrams.
Documentation
Update your man pages for ou, ob, and om.
Christopher Vickery
Computer Science Department,
Queens College of CUNY