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.