We found that the majority of objects in Quake II are self-contained and could easily use the above mechanisms as is. However, a few objects maintained pointers to other objects in the system (e.g., a missile has a pointer to the player that shot it). To avoid having to drastically alter the application, these references must be resolved before presenting replica objects to the application, otherwise the application may dereference a dangling pointer. Pointer resolution would dramatically degrade replication latency if the object manager had to resolve long pointer chains, but in practice, we found that rarely more than one-level of pointers as used (in addition, only pointers that might be dereferenced by a primary's think-code need to be replicated).7 Moreover, in most cases, an interest will encompass both the object and its pointers (e.g., a missile is almost always spatially close to its originator), so both will be replicated simultaneously anyway. To facilitate pointer resolution, a GUID is always transmitted along with the SID of the node maintaining the primary of that GUID. Hence, upon receiving a GUID reference, a node will know who to contact to resolve it.
Note that since objects can migrate between nodes, this SID can become stale. However, since state refresh occurs frequently in games (10 to 20 times a second in FPS games, for example), we believe this scenario will be rare and maintain forwarding pointers (like those in Emerald [24]) to correct stale information.