| OLD | NEW |
| 1 # Mojom protocol | 1 # Mojom protocol |
| 2 | 2 |
| 3 **TODO(vtl)** | 3 The Mojom protocol is the canonical protocol used by 2 communicating mojo |
| 4 applications. Communication is done by sending interface messages (some people |
| 5 call them methods), whose schema is specified using the mojom IDL. This document |
| 6 assumes a basic understanding of the [Mojom IDL](mojom_idl.md). |
| 7 |
| 8 ## Interface messages |
| 9 |
| 10 Communication using the protocol happens between two parties over one |
| 11 communication channel, where the requests flow one way and the responses flow |
| 12 the other. Requests and response schemas are defined by mojom interface message |
| 13 formats. The request and response parameters are each framed as mojom structs, |
| 14 where each parameter is represented by a struct field. |
| 15 |
| 16 The beginning of every request on the wire is framed by an interface message |
| 17 header. There are two versions of the message header: one which includes a |
| 18 'request id', which is used to associate a request with a reply. The other |
| 19 doesn't include a request id. Both versions also include the 'ordinal' (a |
| 20 number) identifying which interface message it is, and some flags indicating if |
| 21 the message is a request expecting a response, a response, etc. |
| 22 |
| 23 Following the message header, a mojom struct representing the request parameters |
| 24 is encoded. This the top-level (i.e., the first) mojom struct that occurs on the |
| 25 wire. |
| 26 |
| 27 ## Mojom struct |
| 28 |
| 29 The wire format of a mojom struct begins with an 8-byte header, followed by |
| 30 bytes representing each field. The fields on the wire appear in packing-order, |
| 31 not ordinal-order (ordinal numbers are implicitly assigned to each field unless |
| 32 they are explicitly assigned one in the IDL). A field's byte-alignment is the |
| 33 same as the field's size (determined by its type); a 4-byte type is 4-byte |
| 34 aligned. In order to make efficient use of the space, fields are packed in the |
| 35 first available block of bytes, which may well be the alignment-padding space. |
| 36 |
| 37 ## Mojom types |
| 38 There are essentially two categories of mojom types: reference (a.k.a pointer) |
| 39 types, and non-reference. |
| 40 |
| 41 ### Non-reference types |
| 42 These are plain-old-data types: `int8`, `uint8`, ..., `int64`, `float32`, |
| 43 `float64`, and sometimes unions (unions can also be reference types -- more on |
| 44 that later). |
| 45 |
| 46 ### Reference types |
| 47 These are types that aren't fixed size. These types include structs, unions |
| 48 (sometimes), arrays, and maps. |
| 49 |
| 50 When a mojom struct field's type is another mojom struct, that field is encoded |
| 51 as a relative byte-offset to where the actual data for the field is. The same |
| 52 applies for mojom arrays and mojom maps. For example: |
| 53 |
| 54 ```mojom |
| 55 struct Child { |
| 56 int32 a; |
| 57 int64 b; |
| 58 int32 c; |
| 59 }; |
| 60 struct Parent { |
| 61 Child childA; |
| 62 Child childB; |
| 63 }; |
| 64 ``` |
| 65 |
| 66 The `Parent` struct is encoded as: |
| 67 Byte Offset | Data | Type | Size | |
| 68 | - | - | - | - | |
| 69 0 | .. | mojom struct header for `struct Parent` | 8 | |
| 70 8 | 16 | offset to `struct Child` | 8 | |
| 71 16 | 32 | offset to `struct Child` | 8 | |
| 72 24 | .. | mojom struct header for `struct Child` | 8 | |
| 73 32 | 666 | int32 | 4 | |
| 74 36 | 666 | int32 | 4 | |
| 75 40 | 666 | int64 | 8 | |
| 76 48 | .. | mojom struct header for `struct Child` | 8 | |
| 77 56 | 666 | int32 | 4 | |
| 78 60 | 666 | int32 | 4 | |
| 79 64 | 666 | int64 | 8 | |
| 80 |
| 81 Here, we see that the actually data for `childA` starts at byte `24`, so the |
| 82 relative byte offset recorded is `16` (i.e., the start of the data is 16 bytes |
| 83 away). Another thing to note is the order of the structs that are encoded: |
| 84 **Referenced structs must be encoded in depth-first order.** That is, the struct |
| 85 referenced by `childA` is encoded before `childB`; similarly, if `struct Child` |
| 86 were to have a reference to another struct, that struct must be encoded before |
| 87 `struct Parent`'s `childB`. |
| 88 |
| 89 In addition to the ordering, there are two more restrictions: |
| 90 1. Referenced objects (structs, arrays, etc.) may only have 1 reference to them. |
| 91 2. Offsets to objects are always positive. |
| 92 |
| 93 While the ordering and the above restrictions are a limiting, it makes certain |
| 94 operations (validation) cheaper. |
| 95 |
| 96 TODO(vardhan): Write about arrays, strings, maps, unions. Maybe this can be in |
| 97 mojom_lang/ instead of intro/? |
| OLD | NEW |