Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(359)

Side by Side Diff: docs/intro/mojom_protocol.md

Issue 2234823005: Initial docs on using the C bindings. (Closed) Base URL: git@github.com:domokit/mojo.git@master
Patch Set: Initial doc for the mojom protocol. Created 4 years, 3 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
« no previous file with comments | « no previous file | no next file » | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
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/?
OLDNEW
« no previous file with comments | « no previous file | no next file » | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698