NSI enables any RPC server with the necessary directory service permissions to create and maintain its own server entries in the namespace. A server can use as many server entries as it needs to advertise combinations of its RPC interfaces and objects.
Each server entry must correspond to a single server (or a group of interchangeable server instances) on a given system. Interchangeable server instances are instances of the same server running on the same system that offer the same RPC objects (if any). Only interchangeable server instances can share a server entry.
Each server entry must contain binding information. Every combination of protocol sequence and network addressing information represents a potential binding. The network addressing information can contain a network address, but lacks an endpoint, making the address partially bound.
A server entry can also contain a list of object UUIDs exported by the server. Each of the object UUIDs corresponds to an object offered by the server. In a given server entry, each interface identifier is associated with every object UUID, but with only the binding information exported with the interface.
The following figure represents a server entry. This server entry was created by two calls to the rpc_ns_binding_export( ) routine. The first call created the first column of the top half of the figure. The routine's binding_vec parameter had three elements, each of which is paired with the routine's if_handle parameter. The vertical ellipsis points under the last box indicate that more elements in the routine's binding_vec parameter would have resulted in more interface UUID/binding information pairs in the first column.
Similarly, the second call to the rpc_ns_binding_export( ) routine created the second column of the top half of the figure. The routine's binding_vec parameter had two elements, each of which is paired with the routine's if_handle parameter. For example, the first element could have contained binding information with the ncacn_ip_tcp protocol sequence, and the second element could have contained binding information with the ncadg_ip_udp protocol sequence. As in the first column, more elements in the routine's binding_vec parameter would have resulted in more interface UUID/binding information pairs.
Third and subsequent calls to the rpc_ns_binding_export( ) routine would create more columns; the two pairs of horizontal ellipsis points indicate this expansion.
Finally, note that the rpc_ns_binding_export( ) routine optionally takes a vector of object UUIDs. The four object UUIDs in the bottom half of the figure came from the two calls to the routine, or from another call to the routine with no interface UUID/version and with no binding information, but with object UUIDs. The object UUIDs are associated with no particular binding. Instead, they are associated with all the bindings. Third and subsequent calls to the routine could create more object UUIDs; the vertical ellipsis points indicate this expansion.
Note: To distinguish among RPC objects when using the CDS ACL editor, export the RPC objects to separate directory service entries.
Possible Information in a Server Entry
