Transfer

发送者只能凭接收者的链路信用 transfer 一条消息，接收者用携带结果的 disposition 结算每一条。

以文字阅读本图

1. 接收者：服务: flow link-credit 256; disposition 针对 128 次投递; flow 再次 link-credit 256
2. 发送者：Broker: transfer 最多到信用为止; transfer 继续
3. flow link-credit 256 → transfer 最多到信用为止: flow
4. transfer 最多到信用为止 → disposition 针对 128 次投递: transfer
5. disposition 针对 128 次投递 → flow 再次 link-credit 256: 一半已结算
6. flow 再次 link-credit 256 → transfer 继续: flow
7. 信用从上一个 flow 起计算 transfer： 服务仍持有的投递不会归还信用

信用是接收者的流控。接收者发送一个带信用的 flow 帧，发送者可以进行这么多次 transfer，然后等待下一个 flow。订阅默认授予 256，credit 可以设置别的数量。

fe2o3-amqp 客户端自己管理信用。每当一半信用已经结算，它就按目前已收到的 transfer 重新授予完整的信用。因此服务工作期间发送者不会断供，也绝不会比上一次授予超前一个以上的窗口。

以文字阅读本图

1. Disposition: accepted; rejected; released; modified delivery-failed
2. Broker: 完成：消息 离开队列; 无效：由 Broker 的 死信策略决定; 未处理：回到 队列，计数不变; 失败：回到 队列，delivery-count + 1
3. accepted → 完成：消息 离开队列
4. rejected → 无效：由 Broker 的 死信策略决定
5. released → 未处理：回到 队列，计数不变
6. modified delivery-failed → 失败：回到 队列，delivery-count + 1
7. 发送者以未结算、已结算或混合（默认）方式发送； 发送时已结算的 transfer 至多投递一次

发送者没有结算的 transfer 一直保持打开，直到接收者用 disposition 应答。它的结果是四种之一。accepted 完成这条消息。rejected 判定它无效，由 Broker 的死信策略决定如何处置。released 把它原样退回，下一次投递带着同样的 delivery-count。带 delivery-failed 的 modified 把它作为一次失败的尝试退回，下一次投递的计数加一。modified 上的 undeliverable-here 要求 Broker 不要再把它投递给这个接收者。

delivery-count 位于消息的 header 段，统计此前失败的尝试次数。各 Broker 对 modified 的处理不同：Artemis 计数，RabbitMQ 4 只在仲裁队列上支持它，Azure Service Bus 不使用它。

流控和结算模式来自规范（传输，第 2.6.7 节和第 2.8 节），结果也来自规范（消息传递，第 3.4 节）。