We saw the AMQP builtin type system, we sent a message to the broker …. now, how is encoded the receive confirmation from the broker itself ?
In this case, the so called performative is the disposition (format code 0x15, page 71 on official specification) that has some fields all filled in a lot of cases.
Of course it has the descriptor 0x00 0x53 and 0x15 as format code and it’s a list 0xC0 with 0x09 bytes distributed on 0x05 fields.
The first field is role that defines the role of the peer that could be sender or receiver. In this case the value is 0x41 that is the “true” value for the boolean type (page 26 of official specification). Why ? What’s the relationship between role and boolean ? The role type is defined as a restricted type that has boolean has source. You can see it like an inheritance because role derives from the existing boolean type restricting and/or changing the mean of the related values using choice (page 73 of official specification). In this case we have that sender is “false” and receiver is “true”. In our case we have 0x41 (true) so the role is the receiver and it’s true because we send a message to the broker (to a queue) and it means that on the other side of the link, the peer is the receiver.
After role, we have first & last fields. Each message sent by the sender has a “delivery-id”. When the receiver sends the disposition to the sender to confirm received message, it needs to set the “delivery-id” of the message itself. It’s possible to define a “delivery-ids” interval so that the receiver can confirm more received messages with a single disposition. The two limits are defined by first and last fields that are of type delivery-number (page 74 of official specification) that is a restricted type with sequence-no as base (it’s a serial number as defined in RFC-1982). In our example the receiver has to confirm only one message so first is 0 and last is null. As you can see, the 0 value is expressed with the byte 0x43 that is a specific and well defined byte used to describe a 0 value (uint0, page 26 of official specification).
Next field is settled that defines the delivery status of the message on the endpoint/peer. This value is also related to the QoS (Quality of Service) and it acts as an aknowledge on messages exchanged. For example, the settled field is in the transfer disposition too; a sender can set it to true and it means to apply a “fire and forget” QoS (the sender sends the message and it isn’t interested to have an acknowledge by the receiver). If the sender set it to false, it expects to receive a disposition with settled to true from receiver (it’s a “at least once” QoS because if the disposition message is lost, the sender re-send the message). Of course, AMQP supports “exactly once” QoS (it isn’t supported by Azure).
In this case its value is 0x41 (true) because it’s defined as a boolean type;
The last field is state that defines the delivery outcome with following possible values :
- accepted : the message was processed by the receiver;
- rejected : indicates an invalid and unprocessable message;
- released : the message was not (and will not be) processed;
- modified : message was modified, but not processed;
Due to the above outcomes, a message can go through following state transitions :
In our example the message was accepted and the field has the descriptor 0x00 0x53 0x24 where the 0x24 format code defines the accepted outcome (page 89 of official specification) that is a list. In this case the list is empty and it’s defined by the byte 0x45 used to describe an “empty list”.