```
0 1 2 3 4 5 6 7 octet
+-------+-------+-------+-------+-------+-------+-------+-------+
-| conn-id | conn-type | conn-spec
+| conn-id | conn-type | flags |
++-------------------------------+---------------+---------------+
+| conn-spec
...
-+-------------------------------+-------------------------------+
-| data-len | data
-+-------------------------------+
++---------------+---------------+-------------------------------+
+| in-data-len | out-resp-len | out-data-len |
++---------------+---------------+-------------------------------+
+| data
...
```
-| Field | Description |
-|-------------|-------------------------------------------------|
-| `conn-id` | A non-zero number used to identify this |
-| | connection in subsequent connection-specific |
-| | records |
-| | |
-| `conn-type` | 0x0000: shared ring |
-| | 0x0001: socket |
-| | 0x0002 - 0xFFFF: reserved for future use |
-| | |
-| `conn-spec` | See below |
-| | |
-| `data-len` | The length (in octets) of any pending data not |
-| | yet written to the connection |
-| | |
-| `data` | Pending data (may be empty) |
+| Field | Description |
+|----------------|----------------------------------------------|
+| `conn-id` | A non-zero number used to identify this |
+| | connection in subsequent connection-specific |
+| | records |
+| | |
+| `conn-type` | 0x0000: shared ring |
+| | 0x0001: socket |
+| | 0x0002 - 0xFFFF: reserved for future use |
+| | |
+| `flags` | A bit-wise OR of: |
+| | 0001: read-only |
+| | |
+| `conn-spec` | See below |
+| | |
+| `in-data-len` | The length (in octets) of any data read |
+| | from the connection not yet processed |
+| | |
+| `out-resp-len` | The length (in octets) of a partial response |
+| | not yet written to the connection |
+| | |
+| `out-data-len` | The length (in octets) of any pending data |
+| | not yet written to the connection, including |
+| | a partial response (see `out-resp-len`) |
+| | |
+| `data` | Pending data: first in-data-len octets of |
+| | read data, then out-data-len octets of |
+| | written data (any of both may be empty) |
-The format of `conn-spec` is dependent upon `conn-type`.
+In case of live update the connection record for the connection via which
+the live update command was issued will contain the response for the live
+update command in the pending not yet written data.
\pagebreak
+The format of `conn-spec` is dependent upon `conn-type`.
+
For `shared ring` connections it is as follows:
```
0 1 2 3 4 5 6 7 octet
- +-------+-------+
- | flags |
+---------------+---------------+---------------+---------------+
| domid | tdomid | evtchn |
+-------------------------------+-------------------------------+
| | it has been subject to an SET_TARGET |
| | operation [2] or DOMID_INVALID [3] otherwise |
| | |
-| `flags` | Must be zero |
-| | |
| `evtchn` | The port number of the interdomain channel used |
| | by `domid` to communicate with xenstored |
| | |
```
- +-------+-------+
- | flags |
+---------------+---------------+---------------+---------------+
| socket-fd | pad |
+-------------------------------+-------------------------------+
| Field | Description |
|-------------|-------------------------------------------------|
-| `flags` | A bit-wise OR of: |
-| | 0001: read-only |
-| | |
| `socket-fd` | The file descriptor of the connected socket |
This type of connection is only relevant for live update, where the xenstored
[3] See https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/xen.h;hb=HEAD#l612
-[4] https://wiki.xen.org/wiki/XenBus
\ No newline at end of file
+[4] https://wiki.xen.org/wiki/XenBus