DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Implementation specific details

Operations

The following sections give a high level description of sequence of operations in common DMI transactions. For a more detailed description see the sample code in ``DMI 2.0 code samples''.

Management application registration

When a management application wishes to interact with a remote station it must first establish a ``remote session''. It establishes the network address of the managed station and which flavour of RPC is to be used for the connection. It then passes this information to the client front end's DmiRemoteRegister(3dmi) function.

The client front end makes a RPC call to the remote ONCSP daemon which decodes it and makes a DmiRegister(3dmi) call to the SP on its own machine. Assuming all is well, the SP returns a handle and ONCSP returns the RPC call. The client front end then returns a handle to the management application which uses it in future DMI transactions with the station.


NOTE: The two handles do not have to have the same value. One uniquely identifies the session on the management station and the other identifies the session on the managed station. The RPC support layers take care of mapping between them.

Progression of a management request

When a management application wishes to make an MI call to a remote station, it first makes the call to the MI interface of its local client front end. The client front end packages the request into an RPC transaction and sends it to the remote station's ONCSP daemon. (The remote station is identified by a handle which was set up during registration.)

The remote ONCSP daemon decodes the request and makes a call to the MI of its local SP. The SP processes the attribute, either via its database or by calling a components CI interface, and returns the result.

ONCSP returns the RPC call. The client front end then returns the result to the management application.

Progression of an event

If a management application wishes to be sent events by a remote station, it must carry out a complex sequence of operations. First it tells the client front end which functions should be called when an indication arrives. A call is made to DmiSetIndicationCallbacks(3dmi) with a list of callback locations within the management application. It then tells the client front end to start listening for indications by the calling DmiIndicationListen(3dmi).

It next tells the managed station where to send indications and which indications to forward. It does this by using standard DMI functions to write entries into tables on the managed station. (See DMI 2.0 specification section 3.3.)

When a component detects that an event has occurred, it makes a call to the CI interface of its local SP. The SP examines its tables and decides which remote stations have currently subscribed to receive the event. It passes this information to the ONCSP daemon by invoking a callback function that was registered when ONCSP started up. ONCSP makes an RPC call to the client front end on the remote machine, which in turn invokes the registered management application callback.

For an example of how this works in practice, see the indcons sample code which is installed with the product in the /usr/src/dmi/samples/MA_support/indcons directory.


Next topic: Implementation details
Previous topic: DMI 2.0 system elements

© 2004 The SCO Group, Inc. All rights reserved.
UnixWare 7 Release 7.1.4 - 27 April 2004