3.2.1.5.2 PDU Forwarding

The RPC over HTTP v2 IN channels and OUT channels that are based on an HTTP or HTTPS transport are half duplex. This means that one party might not be able to send a PDU to another party if the half-duplex channel is going in the other direction. To resolve this problem, RPC over HTTP v2 uses the concept of RTS PDU forwarding. When RTS PDU forwarding is used, a sender MUST mark a PDU as needing forwarding by setting an RTS destination command in the PDU. An implementation of this protocol MUST NOT add a destination command to a RTS PDU that does not have a destination command already. Only RTS PDUs that already have a destination command are subject to forwarding. Once the RTS PDU is marked for forwarding, a sender acts on the fact that only the IN channel between client and inbound proxy and the OUT channel between the client and the outbound proxy are half duplex and MUST send the RTS PDU to the next hop according to the following table.

 Sender

 Destination

 Next hop

client

inbound proxy

direct

client

outbound proxy

inbound proxy

client

server

inbound proxy

inbound proxy

outbound proxy

server

inbound proxy

client

server

inbound proxy

server

direct

outbound proxy

inbound proxy

server

outbound proxy

client

direct

outbound proxy

server

direct

server

inbound proxy

direct

server

outbound proxy

direct

server

client

outbound proxy

If a sender has a "direct" value in the next hop column of the routing table, it MUST NOT use the forwarding mechanism but instead MUST send the PDU directly.

Upon receiving such an RTS PDU, the receiver MUST forward the PDU to the next hop, which MUST be determined by indexing the preceding table by its own role as the value of the sender column and the destination as the value of the destination column.

Show: