Assignment 2, CS-701, Fall 1997

Object Broker Project-- Use Case 3

Use Case 3 -- The Object Broker First Appears

Introduction

The object broker is a third program that acts as an intermediary between object managers and object users. The idea is that there might be several object managers running on the network, and users shouldn't have to know about where they are in order to use them. Instead, object users will contact a single well-known object broker to find out what classes are being managed by what object managers. Object users will then interact with object managers by going through the object broker.

This and the next use case will develop the basic communication patterns among the the object user, object broker, and object manager programs. This case will establish communication between the object broker and the object user, the next case will add communication between the object manager and the object broker, and case five will establish communication between a user and a manager through the broker. Use cases beyond that will implement more of the details of the CSSOOOBP protocol.

Description

The object broker for this use case is almost identical to the object manager you developed for Use Case #2. The difference is in the set of request types that it recognizes:

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. See below for details.
`good-bye`	Anything	"Good-bye acknowledged"	Nothing
`list`	Anything	A string that includes the Argument List. Say something like, "List <Arg List> not implemented." in the string.	Nothing
`shutdown`	Anything	Nothing	Write a message to the log file that includes the Argument List as part of the message, then exit ob.

In the next use case, the "hello" and "good-bye" requests will come from om, but for this use case, we will use ou to send them to ob. For this use case, you can use the same ou that you used in the previous cases, and om is not used at all.

The unique name for a program that is mentioned for "hello" requests is to be in the form <hostname>:<port>, for example, "jaguar:10F3". Given the sockaddr_in struct that is filled in by a call to recvfrom(), you can get the <hostname> by calling gethostbyaddr() and the integer value of remote program's port from the sin_port field of the sockaddr_in struct.

In my implementation I used global variables for the <hostname> and the sockaddr_in struct because the call to recvfrom() is in one part of the program (main()) and the "hello" request is processed in a separate function whose prototype allows only one string argument to be passed to it. You might be able to think of a way to avoid this use of global variables cleanly.

Documentation

You do not need to change your man page for om, but your should check in a copy with revision number 3.1 as part of proper project management. The man page for ou needs to be updated to show what the user may type on the command line and to tell what "hello," "good-bye," "list," and "shutdown" requests will do. You will need to mention ob in your ou man page, but refer the reader to the separate man page for ob in the SEE ALSO section of the page for ou.

The man page for ob, like the pages for other network servers, is oriented more towards users who need to know how to start and stop the server than for end-users. It would be appropriate to list the request types that ob recognizes and to tell what those requests would be used for. Don't describe the internal logic of ob, that should be done in the comments in the code.

Christopher Vickery
Computer Science Department, Queens College of CUNY