Footnotes
1. As in DCE RPC object IDs are indeed only ever interpreted relative to a given computer, this relaxing of the DCE specification is not problematic. [Back]
2. The IID in the interface ID field is from a logical perspective actually redundant because the IPID uniquely specifies an interface pointer (though the IID is not recoverable from just the IPID). However, an additional (optional) check to verify that the caller and callee agree on the type of the interface pointer would make the system more robust. Also, the specification of the actual IID in question eases the integration of the COM network protocol with the DCE RPC network protocol. Note that it is not expensive for callers to provide the IID since the space for the IID is allocated in the DCE RPC header, which is always transmitted anyway. [Back]
3. For the specification of the Connectionless Fault PDU, see [CAE RPC], page 520. Page 535 of the same work describes the Connection-oriented Fault PDU. [Back]
4. Ibid, page 516. [Back]
5. That is, in the Connection-oriented case, the ORPCTHAT also follows four bytes of padding after the fault code; however, the fault code in the Connection-oriented Fault PDU is preceded other data not found in the Connectionless Fault PDU. Consult [CAE RPC] for further details. [Back]
6. Whether one actually thinks of this as a new primitive data type or new compositional operator over existing data types depends on one's point of view. Both positions have some merit. [Back]
7. Note that the object reference does not include the interface identifier (IID), although you can't do much with the object reference without knowing the IID. The IPID does uniquely specify an IID; however, you can't algorithmically derive the IID from the IPID. This is not a problem because the IID does not have to be explicitly specified; it is either implicitly specified (by the type of the argument in a MIDL declaration) or available explicitly as another argument in the call that is carrying the polymorphic object reference (for example, IUnknown::QueryInterface). [Back]
8. A consequence of allowing for this optimizations is that the reference count on each IPID as seen by the server may be in fact less than the total number of references on that interface as seen by all the extant clients of that interface. [Back]
9. This has high probability and not certainty due to some pathological cases involving network failures. Suppose A calls B calls C calls D which will call back to A, and while D is processing its call, the link from B to C goes down, causing B to try to obtain C's services through another party E, which, as D would, calls back to A. In such situations, A may receive incoming calls from both D and E. Only the call from E is actually a potential for deadlock. [Back]
10. Though this decision is subject to review. [Back]
11. In several early specifications the term logical thread ID was used instead of causality ID. The name was changed because the term logical thread ID implies a single threaded model that is not guaranteed. [Back]
12. See [CAE RPC], Appendix H, p 613. [Back]
13. Only if reuse of the DCE RPC Endpoint Mapper endpoints is unacceptable. [Back]
14. This time-out period does not guarantee that OXID information will not be discarded before clients may need it, but is a very good heuristic, and indeed better than a hard-coded time-out value. [Back]
15. That is, adjusting the set's time-out period after the OID has been removed from it has no effect on the time-out of the OID. [Back]
16. Not surprisingly, to get around the chicken-and-egg problem, getting to a remote computer's SCM interface is not done via normal CoCreateInstance means. Richer mechanisms for creating an interface to a remote SCM are TBD, but note that the clarity about the SCM-to-SCM interface and its endpoints ensure interconnectivity. [Back]
17. This is true despite final word whether the Object Exporter will reuse the DCE RPC Endpoint Mapper's endpoints or a different well-known set TBD, as noted above. [Back]