Skip to main content

Path

The way of one AMQP 1.0 delivery through a RustStream service: the pump, the channel, the handler, the reply and the disposition.

The path of one delivery that is answered, from the broker's transfer to its dispositiontransferon the subscription's receiver linkPump task: Receiver::recvheaders from the properties sections,bytes from the data sectionBounded channelas deep as the link creditDispatchone loop, or a lane per keyDecodefrom the delivery's bytesHandlerasync fn under #[subscriber]Replyencoded into the loop's bufferAmqpPublisherholds the address's sender linkuntil the broker's dispositionSettlementa command back to the pump taskdispositionaccepted, modified or rejected
The diagram as text
  1. transfer on the subscription's receiver link → Pump task: Receiver::recv headers from the properties sections, bytes from the data section
  2. Pump task: Receiver::recv headers from the properties sections, bytes from the data section → Bounded channel as deep as the link credit
  3. Bounded channel as deep as the link credit → Dispatch one loop, or a lane per key
  4. Dispatch one loop, or a lane per key → Decode from the delivery's bytes
  5. Decode from the delivery's bytes → Handler async fn under #[subscriber]
  6. Handler async fn under #[subscriber] → Reply encoded into the loop's buffer
  7. Reply encoded into the loop's buffer → AmqpPublisher holds the address's sender link until the broker's disposition
  8. AmqpPublisher holds the address's sender link until the broker's disposition → Settlement a command back to the pump task
  9. Settlement a command back to the pump task → disposition accepted, modified or rejected

A subscription's pump task owns its receiver link. Receiving needs the link to itself, while a settlement only reads it, and the delivery a handler holds has to travel between tasks. So the pump receives, and every settlement comes back to it as a command.

The pump turns a transfer into an AmqpMessage. The headers come from the properties and application-properties sections, the bytes from the data section, and delivery-count from the header section. A string or binary value section is read as bytes too, and any other body is rejected and reported to the subscription. The pump then puts the delivery in a channel as deep as the link credit, and settles commands while it waits for room there.

A delivery the client cannot read, such as one larger than the link allows, is reported and the link stays attached. A broker that transfers past the credit it was given breaks the link, and the subscription ends.

The handler's reply is encoded into a buffer the dispatch loop reuses. The AmqpPublisher takes that buffer as the message's data section, without a copy. It sends the message unsettled on the address's sender link and holds the link until the broker's disposition arrives. So the publishes to one address from one connection go out one at a time, each one round trip. A disposition other than accepted is an error, and a reply that fails to publish settles the delivery with a retry.

The delivery settles after the reply. Its outcome becomes a disposition, as Settlement draws.