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.