2.1.2.1.7 Inbound PDU Stream

Inbound PDUs from the PDU stream MUST be encoded as BLOBs in the message body of the IN channel. The first PDU in the IN channel MUST start from the beginning of the message body of the IN channel, and each subsequent PDU from the PDU stream MUST be placed as a BLOB immediately after the previous PDU in the IN channel without any delimiters. The following diagram describes the layout of the PDUs in the message body of the IN channel.

Figure 10: IN channel message PDU stream

Each PDU is encoded as a variable-sized BLOB containing its length inside the PDU; therefore, no delimiters are necessary between the BLOBs. The length of the RPC PDUs is specified in [C706] section 12, RPC PDU Encodings. The length of the RTS PDUs is defined in section 2.2.3.6 of this specification. An IN channel contains a variable number of PDUs, and the PDUs themselves might have variant sizes. An IN channel MUST NOT contain more PDUs than can fit in its maximum content length as indicated by the Content-Length header. If there is not enough space on an IN channel for another PDU from the PDU stream, the IN channel is considered expired and MUST NOT be used by the client anymore. A successor IN channel MUST be established. For more details on how the client manages the channel lifetime, see section 3.2.2.

The PDUs MUST be sent in the message body as they are generated: PDU N MUST be sent as soon as it is generated and MUST NOT wait for PDU N+1 to be generated.

By using the message body of the IN channel to transmit PDUs over HTTP/HTTPS, this protocol obtains a half-duplex channel for a limited number of bytes that provides reliable, in-order, at-most-once delivery semantics between a client and inbound proxy.