e62ae48fe7a2a9cf584e31ab63bf8cf072c559b7
[polintos/scott/priv.git] / doc / orb / marshalling
1 Segment 0, byte 0 is a request code.  Currently defined codes are:
2  0: Invoke Method
3  1: Get Interface List
4  2: Return Interface List
5
6 Bytes 1-3 (32-bit) and 1-7 (64-bit) are reserved, and must be zero.
7 All offsets described in the rest of this file are relative to the
8 first non-reserved byte (a.k.a. the message payload); however,
9 offsets encoded in the message are relative to the beginning of the
10 segment, not the payload.  The reserved bytes do not need to be
11 included in the message if the payload is empty.
12
13 Op0: Invoke Method
14 ------------------
15
16 The payload begins with the index of the interface being used,
17 followed by the index of the method.  Both are 32-bit integers.
18
19 After that, the payload contains the method's arguments as if they
20 were a struct.
21
22 Non-inline structs and arrays (hereafter referred to as data chunks)
23 which contain object ids and/or references to other data chunks are
24 stored at arbitrary locations in segment 0, and are referenced as an
25 offset into the segment.
26
27 Data chunks which do not contain object ids or references to other
28 data chunks (i.e. they are pure data, and do not need to be altered
29 for marshalling) are stored at arbitrary locations in arbitrary
30 segments.  References to these pure data chunks are encoded as a
31 pointer-sized integer, with the upper N bits holding the segment and
32 the remaining bits holding the offset into that segment.  The value
33 of N is architecture-defined, but should generally be 6 (this may
34 change once enough of the system is in place to do some benchmarks)
35 for 32-bit architectures and 32 for 64-bit architectures.
36
37 Object references are encoded as pointer-sized offsets into the
38 objlist array.
39
40 Virtual structs are prefaced with a header, which consists of
41 the following, in order:
42 1. 32-bit length of vstruct, including header, and all referenced
43 data chunks, which must be contiguously appended to the vstruct body
44 2. 32-bit offset of start of actual struct
45 3. 128-bit GUID of the most derived vstruct type
46 5. 32-bit objlist-offset of the vstruct's object handles, the first
47 of which is introspection object
48 6. 32-bit length of vstruct objlist in handles
49 7. 32-bit offset of an area within the vstruct where the objlist can
50 be copied.
51 8. 32-bit reserved field
52
53 The requirement for all referenced data chunks to be contiguous with
54 the vstruct means that scatter-gather and zero-copy cannot be done;
55 however, it prevents the loss of derived-type data when only a base
56 type is known at unmarshalling time (the derived-type data could
57 later be accessed through introspection, or be passed to another
58 process that does know the derived type).  For this reason, vstructs
59 should generally not be used to pass large chunks of data.
60
61 Likewise, object handles must be preserved even if they are only
62 referenced in an unknown-type portion of the vstruct.  To facilitate
63 this, all handles referenced from the vstruct must be contiguous in
64 the objlist (even if this means duplications), and there must be an
65 area in the vstruct blob where unmarshalling code can copy the
66 translated objlist.
67
68 The introspection object reference at the beginning of the vstruct
69 objlist may be NULL.
70
71 Op1: Get Interface List
72 -----------------------
73
74 Return a "Return Interface List" message corresponding to the object
75 in objlist[0].  For async requests, objlist[1] is the destination for
76 the return message.
77
78 Op2: Return Interface List
79 --------------------------
80
81 For async requests, objlist[1] is the object whose interfaces were
82 requested.
83
84 Segment 1 consists of a list of GUIDs of interfaces that the object
85 supports.