3.2.1.2 ObjectID
Instances in a context have object IDs. The object ID is a 32-bit value that identifies an instance on the server. It is composed of three parts: the group number, the instance number, and the uniqueness value.
The group number identifies the group to which an instance belongs. All instances created for a client share a single group that is associated with that client. In multi-client scenarios, whereby a "master" client hosts plugins, groups are used to ensure that all server resources created for a secondary client are cleaned up when that client terminates.
The instance number identifies a slot in the handle table of a group. Slots in the handle table can be occupied or free as instances are created and deleted. Clients can aggressively reuse low instance numbers to keep the overall table size down, which negates the requirement for specialized sparse storage.
The uniqueness number is a value that is incremented whenever a slot is used for a new instance. Consequently, a reused slot will yield a different handle than the last instance that occupied the slot, which guards against stale handle usage.
Object IDs are managed by the client. Instance creation requests to the server always include the object ID that is pre-allocated by the server. The server MUST populate its handle table based on the IDs it receives from the client in the creation requests. The handle table of the server is a cached copy of the handle table of the client. This configuration allows instance creation to be asynchronous and pipelined, which further enables quick creation and configuration of complex scenes with minimal round tripping. It is extremely common for a client to send messages that create, use, and destroy an object within a single batch buffer, even by reusing the same handle slot for multiple objects in that buffer.
The number of bits within the Object ID that are devoted to the group, instance, and uniqueness values is variable and specified by the client upon connection (see section 2.2.1.2).
When servicing a creation request, the server MUST use the group and instance numbers to find the slot in the relevant handle table. It MUST validate that the slot is not in use before satisfying the request.
When decoding an Object ID reference, the server MUST use the group and instance numbers to find the slot in the relevant handle table. It MUST validate that the slot is in use and that the uniqueness value from the Object ID matches the current uniqueness value for the slot.
If any of the above validations fail, the server MUST treat the condition as fatal and close the connection.