Share via

3.1.1.1 Abstract Data Model

  • Article

This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The organization is provided to explain how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that specified in this document.

Object exporters MUST maintain the following data elements:

Authentication level: The authentication level of the object exporter.

Permissions: An implementation-specific set of permissions that determine who can access the object exporter.

IPID table: A table of entries to interfaces on objects, keyed by IPID or IID. Each entry MUST contain:

  • The IPID of the interface.

  • The IID of the interface.

  • The OID of the object.

  • The OXID of the object exporter.

  • The public reference counts of the object reference.

  • A list of private reference counts, one per client identity.

  • A pointer to an application defined state for the object's implementation of the interface.

OID table: A table information about objects referenced by the client, keyed by OID or object pointer. Each entry MUST contain:

  • The OID of the object.

  • The OXID of the object exporter.

  • A list of IPIDs of the interfaces on the object.

  • The time of the last ORPC invocation on the OID.

  • An object pointer to an implementation-specific application state that represents the object.

  • An implementation-defined hash of the STRINGBINDING of the saResAddr field contained in the STDOBJREF.

  • A Boolean garbage_collection flag that MUST be set to True if the object participates in pinging; see the SORF_NOPING flag in section 2.2.18.2.

Resolver table: See section 3.2.1.

SETID table: See section 3.2.1.

OXID table: See section 3.2.1.