The AMQP Network consists of Nodes connected via Links. Nodes are named entities responsible for the safe storage and/or delivery of Messages. Messages can originate from, terminate at, or be relayed by Nodes.

A Link is a unidirectional route between two Nodes. Links attach to a Node at a Terminus. There are two kinds of Terminus: Sources and Targets. A Terminus is responsible for tracking the state of a particular stream of incoming or outgoing messages. Sources track outgoing messages and Targets track incoming messages. Messages may only travel along a Link if they meet the entry criteria at the Source.

As a Message travels through the AMQP network, the responsibility for safe storage and delivery of the Message is transferred between the Nodes it encounters. The Link Protocol (defined in ) manages the transfer of responsibility between the Source and Target.

Nodes exist within a Container, and each Container may hold many Nodes. Examples of AMQP Nodes are Producers, Consumers, and Queues. Producers and Consumers are the elements within a client Application that generate and process Messages. Queues are entities within a Broker that store and forward Messages. Examples of containers are Brokers and Client Applications.

The AMQP Transport Specification defines a peer-to-peer protocol for transferring Messages between Nodes in the AMQP network. This portion of the specification is not concerned with the internal workings of any sort of Node, and only deals with the mechanics of unambiguously transferring a Message from one Node to another.

Containers communicate via Connections. An AMQP Connection consists of a full-duplex, reliably ordered sequence of Frames. The precise requirement for a Connection is that if the n^th Frame arrives, all Frames prior to n MUST also have arrived. It is assumed Connections are transient and may fail for a variety of reasons resulting in the loss of an unknown number of frames, but they are still subject to the aforementioned ordered reliability criteria. This is similar to the guarantee that TCP or SCTP provides for byte streams, and the specification defines a framing system used to parse a byte stream into a sequence of Frames for use in establishing an AMQP Connection (see ).

An AMQP Connection is divided into a negotiated number of independent unidirectional Channels. Each Frame is marked with the Channel number indicating its parent Channel, and the Frame sequence for each Channel is multiplexed into a single Frame sequence for the Connection.

An AMQP Session correlates two unidirectional Channels to form a bidirectional, sequential conversation between two Containers. A single Connection may have multiple independent Sessions active simultaneously, up to the negotiated Channel limit. Both Connections and Sessions are modeled by each peer as endpoints that store local and last known remote state regarding the Connection or Session in question.

Sessions provide the context for communication between Sources and Targets. A Link Endpoint associates a Terminus with a Session Endpoint. Within a Session, the Link Protocol (defined in ) is used to establish Links between Sources and Targets and to transfer Messages across them. A single Session may be simultaneously associated with any number of Links.

A Frame is the unit of work carried on the wire. Connections have a negotiated maximum frame size allowing byte streams to be easily defragmented into complete frame bodies representing the independently parsable units formally defined in . The following table lists all frame bodies and defines which endpoints handle them.

Prior to sending any Frames on a Connection, each peer MUST start by sending a protocol header that indicates the protocol version used on the Connection. The protocol header consists of the upper case ASCII letters "AMQP" followed by a protocol id of zero, followed by three unsigned bytes representing the major, minor, and revision of the protocol version (currently , , ). In total this is an 8-octet sequence:

Any data appearing beyond the protocol header MUST match the version indicated by the protocol header. If the incoming and outgoing protocol headers do not match, both peers MUST close their outgoing stream and SHOULD read the incoming stream until it is terminated.

The AMQP peer which acted in the role of the TCP client (i.e. the peer that opened the Connection) MUST immediately send its outgoing protocol header on establishment of the TCP Session. The AMQP peer which acted in the role of the TCP server MAY elect to wait until receiving the incoming protocol header before sending its own outgoing protocol header.

Two AMQP peers agree on a protocol version as follows (where the words "client" and "server" refer to the roles being played by the peers at the TCP Connection level):

• When the client opens a new socket Connection to a server, it MUST send a protocol header with the client's preferred protocol version.

• If the requested protocol version is supported, the server MUST send its own protocol header with the requested version to the socket, and then proceed according to the protocol definition.

• If the requested protocol version is not supported, the server MUST send a protocol header with a supported protocol version and then close the socket.

• When choosing a protocol version to respond with, the server SHOULD choose the highest supported version that is less than or equal to the requested version. If no such version exists, the server SHOULD respond with the highest supported version.

• If the server can't parse the protocol header, the server MUST send a valid protocol header with a supported protocol version and then close the socket.

Based on this behavior a client can discover which protocol versions a server supports by attempting to connect with its highest supported version and reconnecting with a version less than or equal to the version received back from the server.

Please note that the above examples use the literal notation defined in RFC 2234 for non alphanumeric values.

The protocol id is not a part of the protocol version and thus the rule above regarding the highest supported version does not apply. A client might request use of a protocol id that is unacceptable to a server - for example, it might request a raw AMQP connection when the server is configured to require a TLS or SASL security layer (See ). In this case, the server MUST send a protocol header with an acceptable protocol id (and version) and then close the socket. It MAY choose any protocol id.

Frames are divided into three distinct areas: a fixed width frame header, a variable width extended header, and a variable width frame body.

frame header

The frame header is a fixed size (8 byte) structure that precedes each frame. The frame header includes mandatory information required to parse the rest of the frame including size and type information.

extended header

The extended header is a variable width area preceding the frame body. This is an extension point defined for future expansion. The treatment of this area depends on the frame type.

frame body

The frame body is a variable width sequence of bytes the format of which depends on the frame type.

The diagram below shows the details of the general frame layout for all frame types.

SIZE

Bytes 0-3 of the frame header contain the frame size. This is an unsigned 32-bit integer that MUST contain the total frame size of the frame header, extended header, and frame body. The frame is malformed if the size is less than the size of the required frame header (8 bytes).

DOFF

Byte 4 of the frame header is the data offset. This gives the position of the body within the frame. The value of the data offset is unsigned 8-bit integer specifying a count of 4 byte words. Due to the mandatory 8 byte frame header, the frame is malformed if the value is less than 2.

TYPE

Byte 5 of the frame header is a type code. The type code indicates the format and purpose of the frame. The subsequent bytes in the frame header may be interpreted differently depending on the type of the frame. A type code of 0x00 indicates that the frame is an AMQP frame. (A type code of 0x01 indicates that the frame is a SASL frame, see ).

Bytes 6 and 7 of an AMQP Frame contain the Channel number (see ). The frame body is defined as a performative followed by an opaque payload. The performative MUST be one of those defined in and is encoded as a described type in the AMQP type system. The remaining bytes in the frame body form the payload for that frame. The presence and format of the payload is defined by the semantics of the given performative.

An AMQP frame with no body may be used to generate artificial traffic as needed to satisfy any negotiated idle time-out interval. See .

AMQP Connections are divided into a number of unidirectional Channels. A Connection Endpoint contains two kinds of Channel endpoints: incoming and outgoing. A Connection Endpoint maps incoming Frames other than and to an incoming Channel endpoint based on the incoming Channel number, as well as relaying Frames produced by outgoing Channel endpoints, marking them with the associated outgoing Channel number before sending them.

This requires Connection endpoints to contain two mappings. One from incoming Channel number to incoming Channel endpoint, and one from outgoing Channel endpoint, to outgoing Channel number.

Channels are unidirectional, and thus at each Connection endpoint the incoming and outgoing Channels are completely distinct. Channel numbers are scoped relative to direction, thus there is no causal relation between incoming and outgoing Channels that happen to be identified by the "same" number. This means that if a bidirectional endpoint is constructed from an incoming Channel endpoint and an outgoing Channel endpoint, the Channel number used for incoming Frames is not necessarily the same as the Channel number used for outgoing Frames.

Although not strictly directed at the Connection endpoint, the and Frames may be useful for the Connection endpoint to intercept as these Frames are how Sessions mark the beginning and ending of communication on a given Channel (see ).

Each AMQP Connection begins with an exchange of capabilities and limitations, including the maximum frame size. Prior to any explicit negotiation, the maximum frame size is and the maximum channel number is 0. After establishing or accepting a TCP Connection and sending the protocol header, each peer must send an frame before sending any other Frames. The frame describes the capabilities and limits of that peer. The frame can only be sent on channel 0. After sending the frame each peer must read its partner's frame and must operate within mutually acceptable limitations from this point forward.

For applications that use many short-lived Connections, it may be desirable to pipeline the Connection negotiation process. A peer may do this by starting to send subsequent frames before receiving the partner's Connection header or frame. This is permitted so long as the pipelined frames are known a priori to conform to the capabilities and limitations of its partner. For example, this may be accomplished by keeping the use of the Connection within the capabilities and limits expected of all AMQP implementations as defined by the specification of the frame.

The use of pipelined frames by a peer cannot be distinguished by the peer's partner from non-pipelined use so long as the pipelined frames conform to the partner's capabilities and limitations.

Prior to closing a Connection, each peer MUST write a frame with a code indicating the reason for closing. This frame MUST be the last thing ever written onto a Connection. After writing this frame the peer SHOULD continue to read from the Connection until it receives the partner's frame (in order to guard against erroneously or maliciously implemented partners, a peer SHOULD implement a timeout to give its partner a reasonable time to receive and process the close before giving up and simply closing the underlying transport mechanism). A frame may be received on any channel up to the maximum channel number negotiated in open. However, implementations SHOULD send it on channel 0, and MUST send it on channel 0 if pipelined in a single batch with the corresponding .

Implementations SHOULD NOT expect to be able to reuse open TCP sockets after performatives have been exchanged. There is no requirement for an implementation to read from a socket after a performative has been received.

Normally one peer will initiate the Connection close, and the partner will send its close in response. However, because both endpoints may simultaneously choose to close the Connection for independent reasons, it is possible for a simultaneous close to occur. In this case, the only potentially observable difference from the perspective of each endpoint is the code indicating the reason for the close.

Connections are subject to an idle time-out threshold. The time-out is triggered by a local peer when no frames are received after a threshold value is exceeded. The idle time-out is measured in milliseconds, and starts from the time the last frame is received. If the threshold is exceeded, then a peer should try to gracefully close the connection using a frame with an error explaining why. If the remote peer does not respond gracefully within a threshold to this, then the peer may close the TCP socket.

Each peer has its own (independent) idle time-out. At Connection open each peer communicates the maximum period between activity (frames) on the connection that it desires from its partner. The frame carries the idle-time-out field for this purpose. To avoid spurious time-outs, the value in idle-time-out should be half the peer's actual timeout threshold.

If a peer can not, for any reason support a proposed idle time-out, then it should close the connection using a frame with an error explaining why. There is no requirement for peers to support arbitrarily short or long idle time-outs.

The use of idle time-outs is any addition to any network protocol level control. Implementations should make use of TCP keep-alive wherever possible in order to be good citizens.

If a peer needs to satisfy the need to send traffic to prevent idle time-out, and has nothing to send, it may send an empty frame, i.e. a frame consisting solely of a frame header, with no frame body. This frame's channel can be any valid channel up to channel-max, but is otherwise to be ignored. Implementations SHOULD use channel 0 for empty frames, and MUST use channel 0 if channel-max has not yet been negotiated (i.e. before an frame has been received). Apart from this use, empty frames have no meaning.

Empty frames can only be sent after the frame is sent. As they are a frame, they should not be sent after the frame has been sent.

As an alternative to using an empty frame to prevent an idle time-out, if a connection is in a permissible state, an implementation MAY choose to send a flow frame for a valid session.

If during operation a peer exceeds the remote peer's idle time-out's threshold, e.g. because it is heavily loaded, it SHOULD gracefully close the connection by using a frame with an error explaining why.

START

In this state a Connection exists, but nothing has been sent or received. This is the state an implementation would be in immediately after performing a socket connect or socket accept.

HDR_RCVD

In this state the Connection header has been received from our peer, but we have not yet sent anything.

HDR_SENT

In this state the Connection header has been sent to our peer, but we have not yet received anything.

OPEN_PIPE

In this state we have sent both the Connection header and the frame, but we have not yet received anything.

OC_PIPE

In this state we have sent the Connection header, the frame, any pipelined Connection traffic, and the frame, but we have not yet received anything.

OPEN_RCVD

In this state we have sent and received the Connection header, and received an frame from our peer, but have not yet sent an frame.

OPEN_SENT

In this state we have sent and received the Connection header, and sent an frame to our peer, but have not yet received an frame.

CLOSE_PIPE

In this state we have send and received the Connection header, sent an frame, any pipelined Connection traffic, and the frame, but we have not yet received an frame.

OPENED

In this state the Connection header and the frame have both been sent and received.

CLOSE_RCVD

In this state we have received a frame indicating that our partner has initiated a close. This means we will never have to read anything more from this Connection, however we can continue to write frames onto the Connection. If desired, an implementation could do a TCP half-close at this point to shutdown the read side of the Connection.

CLOSE_SENT

In this state we have sent a frame to our partner. It is illegal to write anything more onto the Connection, however there may still be incoming frames. If desired, an implementation could do a TCP half-close at this point to shutdown the write side of the Connection.

DISCARDING

The DISCARDING state is a variant of the CLOSE_SENT state where the is triggered by an error. In this case any incoming frames on the connection MUST be silently discarded until the peer's frame is received.

END

In this state it is illegal for either endpoint to write anything more onto the Connection. The Connection may be safely closed and discarded.

The graph below depicts a complete state diagram for each endpoint. The boxes represent states, and the arrows represent state transitions. Each arrow is labeled with the action that triggers that particular transition.

A Session is a bidirectional sequential conversation between two containers that provides a grouping for related links. Sessions serve as the context for link communication. Any number of links of any directionality can be attached to a given Session. However, a link may be attached to at most one Session at a time.

Messages transferred on a link are sequentially identified within the Session. A session may be viewed as multiplexing link traffic, much like a connection multiplexes session traffic. However, unlike the sessions on a connection, links on a session are not entirely independent since they share a common delivery sequence scoped to the session. This common sequence allows endpoints to efficiently refer to sets of deliveries regardless of the originating link. This is of particular benefit when a single application is receiving messages along a large number of different links. In this case the session provides aggregation of otherwise independent links into a single stream that can be efficiently acknowledged by the receiving application.

Sessions are established by creating a Session Endpoint, assigning it to an unused channel number, and sending a announcing the association of the Session Endpoint with the outgoing channel. Upon receiving the the partner will check the remote-channel field and find it empty. This indicates that the begin is referring to remotely initiated Session. The partner will therefore allocate an unused outgoing channel for the remotely initiated Session and indicate this by sending its own setting the remote-channel field to the incoming channel of the remotely initiated Session.

To make it easier to monitor AMQP sessions, it is recommended that implementations always assign the lowest available unused channel number.

The remote-channel field of a frame MUST be empty for a locally initiated Session, and MUST be set when announcing the endpoint created as a result of a remotely initiated Session.

Sessions end automatically when the Connection is closed or interrupted. Sessions are explicitly ended when either endpoint chooses to end the Session. When a Session is explicitly ended, an frame is sent to announce the disassociation of the endpoint from its outgoing channel, and to carry error information when relevant.

Due to the potentially asynchronous nature of Sessions, it is possible that both peers may simultaneously decide to end a Session. If this should happen, it will appear to each peer as though their partner's spontaneously initiated frame is actually an answer to the peers initial frame.

When a Session is unable to process input, it MUST indicate this by issuing an END with an appropriate indicating the cause of the problem. It MUST then proceed to discard all incoming frames from the remote endpoint until hearing the remote endpoint's corresponding frame.

UNMAPPED

In the UNMAPPED state, the Session endpoint is not mapped to any incoming or outgoing channels on the Connection endpoint. In this state an endpoint cannot send or receive frames.

BEGIN_SENT

In the BEGIN_SENT state, the Session endpoint is assigned an outgoing channel number, but there is no entry in the incoming channel map. In this state the endpoint may send frames but cannot receive them.

BEGIN_RCVD

In the BEGIN_RCVD state, the Session endpoint has an entry in the incoming channel map, but has not yet been assigned an outgoing channel number. The endpoint may receive frames, but cannot send them.

MAPPED

In the MAPPED state, the Session endpoint has both an outgoing channel number and an entry in the incoming channel map. The endpoint may both send and receive frames.

END_SENT

In the END_SENT state, the Session endpoint has an entry in the incoming channel map, but is no longer assigned an outgoing channel number. The endpoint may receive frames, but cannot send them.

END_RCVD

In the END_RCVD state, the Session endpoint is assigned an outgoing channel number, but there is no entry in the incoming channel map. The endpoint may send frames, but cannot receive them.

DISCARDING

The DISCARDING state is a variant of the END_SENT state where the is triggered by an error. In this case any incoming frames on the session MUST be silently discarded until the peer's frame is received.

There is no obligation to retain a Session Endpoint when it is in the UNMAPPED state, i.e. the UNMAPPED state is equivalent to a NONEXISTENT state.

The Session Endpoint assigns each outgoing frame an implicit transfer-id from a session scoped sequence. Each session endpoint maintains the following state to manage incoming and outgoing frames:

next-incoming-id

The next-incoming-id identifies the implicit transfer-id of the next incoming frame.

incoming-window

The incoming-window defines the maximum number of incoming frames that the endpoint can currently receive. This identifies a current maximum incoming transfer-id that can be computed by subtracting one from the sum of incoming-window and next-incoming-id.

next-outgoing-id

The next-outgoing-id is used to assign a unique transfer-id to all outgoing transfer frames on a given session. The next-outgoing-id may be initialized to an arbitrary value and is incremented after each successive according to RFC-1982 serial number arithmetic.

outgoing-window

The outgoing-window defines the maximum number of outgoing frames that the endpoint can currently send. This identifies a current maximum outgoing transfer-id that can be computed by subtracting one from the sum of outgoing-window and next-outgoing-id.

remote-incoming-window

The remote-incoming-window reflects the maximum number of outgoing transfers that can be sent without exceeding the remote endpoint's incoming-window. This value MUST be decremented after every frame is sent, and recomputed when informed of the remote session endpoint state.

remote-outgoing-window

The remote-outgoing-window reflects the maximum number of incoming transfers that may arrive without exceeding the remote endpoint's outgoing-window. This value MUST be decremented after every incoming frame is received, and recomputed when informed fo the remote session endpoint state. When this window shrinks, it is an indication of outstanding transfers. Settling outstanding transfers may cause the window to grow.

Once initialized, this state is updated by various events that occur in the lifespan of a session and its associated links:

sending a transfer

Upon sending a transfer, the sending endpoint will increment its next-outgoing-id, decrement its remote-incoming-window, and may (depending on policy) decrement its outgoing-window.

receiving a transfer

Upon receiving a transfer, the receiving endpoint will increment the next-incoming-id to match the implicit transfer-id of the incoming transfer plus one, as well as decrementing the remote-outgoing-window, and may (depending on policy) decrement its incoming-window.

receiving a flow

When the endpoint receives a frame from its peer, it MUST update the next-incoming-id directly from the next-outgoing-id of the frame, as well as copy the remote-outgoing-window directly from the outgoing-window of the frame.

The remote-incoming-window is computed as follows:

next-incoming-id_flow + incoming-window_flow - next-outgoing-id_endpoint

If the next-incoming-id field of the frame is not set, then remote-incoming-window is computed as follows:

initial-outgoing-id_endpoint + incoming-window_flow - next-outgoing-id_endpoint

A Link provides a unidirectional transport for Messages between a Source and a Target. The primary responsibility of a Source or Target (a Terminus) is to maintain a record of the status of each active delivery attempt until such a time as it is safe to forget. These are referred to as unsettled deliveries. When a Terminus forgets the state associated with a delivery-tag, it is considered settled. Each delivery attempt is assigned a unique delivery-tag at the Source. The status of an active delivery attempt is known as the Delivery State of the delivery.

Link Endpoints interface between a Terminus and a Session Endpoint, and maintain additional state used for active communication between the local and remote endpoints. Link Endpoints therefore come in two flavors: Senders and Receivers. When the sending application submits a Message to the Sender for transport, it also supplies the delivery-tag used by the Source to track the Delivery State. The Link Endpoint assigns each Message a unique delivery-id from a Session scoped sequence. These delivery-ids are used to efficiently reference subsets of the outstanding deliveries on a Session.

Termini may exist beyond their associated Link Endpoints, so it is possible for a Session to terminate and the Termini to remain. A Link is said to be suspended if the Termini exist, but have no associated Link Endpoints. The process of associating new Link Endpoints with existing Termini and re-establishing communication is referred to as resuming a Link.

The original Link Endpoint state is not necessary for resumption of a Link. Only the unsettled Delivery State maintained at the Termini is necessary for link resume, and this need not be stored directly. The form of delivery-tags is intentionally left open-ended so that they and their related Delivery State can, if desired, be (re)constructed from application state, thereby minimizing or eliminating the need to retain additional protocol-specific state in order to resume a Link.

Links are named so that they may be recovered when communication is interrupted. Link names MUST uniquely identify the link amongst all links of the same direction between the two participating containers. Link names are only used when attaching a Link, so they may be arbitrarily long without a significant penalty.

A link's name uniquely identifies the link from the container of the source to the container of the target node, e.g. if the container of the source node is A, and the container of the target node is B, the link may be globally identified by the (ordered) tuple (A,B,<name>).

Consequently, a link may only be active in one connection at a time. If an attempt is made to attach the link subsequently when it is not suspended, then the link can be 'stolen', i.e. the second attach succeeds and the first attach must then be closed with a link error of . This behavior ensures that in the event of a connection failure occurring and being noticed by one party, that re-establishment has the desired effect.

Each Link Endpoint is assigned a numeric handle used by the peer as a shorthand to refer to the Link in all frames that reference the Link (, , , , ). This handle is assigned by the initial frame and remains in use until the link is detached. The two Endpoints are not required to use the same handle. This means a peer is free to independently chose its handle when a Link Endpoint is associated with the Session. The locally chosen handle is referred to as the output handle. The remotely chosen handle is referred to as the input handle.

At an Endpoint, a Link is considered to be attached when the Link Endpoint exists and has both input and output handles assigned at an active Session Endpoint. A Link is considered to be detached when the Link Endpoint exists, but is not assigned either input or output handles. A Link can be considered half attached (or half detached) when only one of the input or output handles is assigned.

Links are established and/or resumed by creating a Link Endpoint associated with a local Terminus, assigning it to an unused handle, and sending an Frame. This frame carries the state of the newly created Link Endpoint, including the local and remote termini, one being the source and one being the target depending on the directionality of the Link Endpoint. On receipt of the , the remote Session Endpoint creates a corresponding Link Endpoint and informs its application of the attaching Link. The application attempts to locate the Terminus previously associated with the Link. This Terminus is associated with the Link Endpoint and may be updated if its properties do not match those sent by the remote Link Endpoint. If no such Terminus exists, the application MAY choose to create one using the properties supplied by the remote Link Endpoint. The Link Endpoint is then mapped to an unused handle, and an Frame is issued carrying the state of the newly created endpoint. Note that if the application chooses not to create a Terminus, the Session Endpoint will still create a Link Endpoint and issue an indicating that the Link Endpoint has no associated local terminus. In this case, the Session Endpoint MUST immediately detach the newly created Link Endpoint.

If there is no pre-existing Terminus, and the peer does not wish to create a new one, this is indicated by setting the local terminus (source or target as appropriate) to null.

If either end of the Link is already associated with a Terminus, the frame MUST include its unsettled delivery state.

Note that the expected Terminus properties may not always match the actual Terminus properties reported by the remote endpoint. In this case, the Link is always considered to be between the Source as described by the Sender, and the Target as described by the Receiver. This can happen both when establishing and when resuming a link.

When a link is established, an endpoint may not have all the capabilities necessary to create the terminus exactly matching the expectations of the peer. Should this happen, the endpoint MAY adjust the properties in order to succeed in creating the terminus. In this case the endpoint MUST report the actual properties of the terminus as created.

When resuming a link, the Source and Target properties may have changed while the link was suspended. When this happens, the Termini properties communicated in the source and target fields of the frames may be in conflict. In this case, the Sender is considered to hold the authoritative version of the Source properties, the Receiver is considered to hold the authoritative version of the Target properties. As above, the resulting Link is constructed to be between the Source as described by the Sender, and the Target as described by the Receiver. Once the Link is resumed, either peer is free to continue if the updated properties are acceptable, or if not, .

Note that a peer MUST take responsibility for verifying that the remote terminus meets its requirements. The remote peer SHOULD NOT attempt to pre-empt whether the terminus will meet the requirements of its partner. This is equally true both for creating and resuming links.

It is possible to resume a Link even if one of the Termini has lost nearly all its state. All that is required is the Link name and direction. This is referred to as recovering a Link. This is done by creating a new Link Endpoint with an empty source or target for incoming or outgoing Links respectively. The full Link state is then constructed from the authoritative source or target supplied by the other endpoint once the Link is established. If the remote peer has no record of the Link, then no terminus will be located, and local terminus (source or target as appropriate) field in the frame will be null.

A Session Endpoint can choose to unmap its output handle for a Link. In this case, the endpoint MUST send a frame to inform the remote peer that the handle is no longer attached to the Link Endpoint. Should both endpoints do this, the Link may return to a fully detached state. Note that in this case the Link Endpoints may still indirectly communicate via the Session, as there may be active deliveries on the link referenced via delivery-id.

When the state of a Link Endpoint changes, this is can be communicated by detaching and then reattaching with the updated state on the frame. This can be used to update the properties of the link endpoints, or to update the properties of the Termini.

When an error occurs at a Link Endpoint, the endpoint MUST be detached with appropriate error information supplied in the error field of the frame. The Link Endpoint MUST then be destroyed. Should any input (other than a detach) related to the endpoint either via the input handle or delivery-ids be received, the session MUST be terminated with an session-error. Since the Link Endpoint has been destroyed, the peer cannot reattach, and MUST resume the link in order to restore communication. In order to disambiguate the resume request from a pipelined re-attach the resuming performative MUST contain a non-null value for its unsettled field. Receipt of a pipelined MUST result in the session being terminated with an session-error.

A peer closes a Link by sending the frame with the handle for the specified Link, and the closed flag set to true. The partner will destroy the corresponding Link endpoint, and reply with its own frame with the closed flag set to true.

Note that one peer may send a closing detach while its partner is sending a non-closing detach. In this case, the partner MUST signal that it has closed the link by reattaching and then sending a closing detach.

Once attached, a Link is subject to flow control of Message transfers. Link Endpoints maintain the following flow control state. This state defines when it is legal to send transfers on an attached Link, as well as indicating when certain interesting conditions, such as insufficient messages to consume the currently available link-credit, or insufficient link-credit to send available messages:

delivery-count

The delivery-count is initialized by the Sender when a Link Endpoint is created, and is incremented whenever a Message is sent (at the Sender) or received (at the Receiver). Only the Sender may independently modify this field. The Receiver's value is calculated based on the last known value from the Sender and any subsequent Messages received on the Link.

link-credit

The link-credit variable defines the current maximum legal amount that the delivery-count may be increased. This identifies a delivery-limit that may be computed by adding the link-credit to the delivery-count.

Only the Receiver can independently choose a value for this field. The Sender's value MUST always be maintained in such a way as to match the delivery-limit identified by the Receiver. This means that the Sender's link-credit variable MUST be set according to this formula when flow information is given by the receiver:

link-credit_snd := delivery-count_rcv + link-credit_rcv - delivery-count_snd.

In the event that the receiver does not yet know the delivery-count, i.e. delivery-count_rcv is unspecified, the Sender MUST assume that the delivery-count_rcv is the first delivery-count_snd sent from Sender to Receiver, i.e. the delivery-count_snd specified in the flow state carried by the initial frame from the Sender to the Receiver.

Additionally, whenever the Sender increases delivery-count, it MUST decrease link-credit by the same amount in order to maintain the delivery-limit identified by the Receiver.

available

The available variable is controlled by the Sender, and indicates to the Receiver, that the Sender could make use of the indicated amount of link-credit. Only the Sender can independently modify this field. The Receiver's value is calculated based on the last known value from the Sender and any subsequent incoming Messages received. The Sender MAY transfer Messages even if the available variable is zero. Should this happen, the Receiver MUST maintain a floor of zero in it's calculation of the value of available.

drain

The drain flag indicates how the Sender should behave when insufficient messages are available to consume the current link-credit. If set, the Sender will (after sending all available messages) advance the delivery-count as much as possible, consuming all link-credit, and send the flow state to the Receiver. Only the Receiver can independently modify this field. The Sender's value is always the last known value indicated by the Receiver.

If the link-credit is less than or equal to zero, i.e. the delivery-count is the same as or greater than the delivery-limit, it is illegal to send more messages. If the link-credit is reduced by the Receiver when transfers are in-flight, the Receiver MAY either handle the excess messages normally or detach the Link with a transfer-limit-exceeded error code.

If the Sender's drain flag is set and there are no available messages, the Sender MUST advance its delivery-count until link-credit is zero, and send its updated state to the Receiver.

The delivery-count is an absolute value. While the value itself is conceptually unbounded, it is encoded as a 32-bit integer that wraps around and compares according to RFC-1982 serial number arithmetic.

The initial flow state of a Link Endpoint is determined as follows. The link-credit and available variables are initialized to zero. The drain flag is initialized to False. The Sender may choose an arbitrary point to initialize the delivery-count. This value is communicated in the initial frame. The Receiver initializes its delivery-count upon receiving the Sender's .

The flow control semantics defined in this section provide the primitives necessary to implement a wide variety of flow control strategies. Additionally, by manipulating the link-credit and drain flag, a Receiver can provide a variety of different higher level behaviors often useful to applications, including synchronous blocking fetch, synchronous fetch with a timeout, asynchronous notifications, and stopping/pausing.

A synchronous get of a message from a Link is accomplished by incrementing the link-credit, sending the updated state, and waiting indefinitely for a to arrive.

Synchronous get with a timeout is accomplished by incrementing the link-credit, sending the updated state and waiting for the link-credit to be consumed. When the desired time has elapsed the Receiver then sets the drain flag and sends the newly updated state again, while continuing to wait for the link-credit to be consumed. Even if no messages are available, this condition will be met promptly because of the drain flag. Once the link-credit is consumed, the Receiver can unambiguously determine whether a message has arrived or whether the operation has timed out.

Asynchronous notification can be accomplished as follows. The receiver maintains a target amount of link-credit for that Link. As transfers arrive on the Link, the Sender's link-credit decreases as the delivery-count increases. When the Sender's link-credit falls below a threshold, the state may be sent to increase the Sender's link-credit back to the desired target.

Stopping the transfers on a given Link is accomplished by updating the link-credit to be zero and sending the updated state. Some transfers may be in-flight at the time the state is sent, so incoming transfers may still arrive on the Link. The echo field of the frame may be used to request the Sender's state be echoed back. This may be used to determine when the Link has finally quiesced.

The transport layer assumes as little as possible about Messages and allows alternative Message representations to be layered above. Message data is carried as the payload in frames containing the performative. Messages can be fragmented across several frames as indicated by the more flag of the performative.

When an application initiates a message transfer, it assigns a delivery-tag used to track the state of the delivery while the message is in transit. A delivery is considered unsettled at the sender/receiver from the point at which it was sent/received until it has been settled by the sending/receiving application. Each delivery MUST be identified by a delivery-tag chosen by the sending application. The delivery-tag MUST be unique amongst all deliveries that could be considered unsettled by either end of the Link.

Upon initiating a transfer, the application will supply the sending link endpoint (Sender) with the message data and its associated delivery-tag. The Sender will create an entry in its unsettled map, and send a transfer frame that includes the delivery-tag, its initial state, and its associated message data. For brevity on the wire, the delivery-tag is also associated with a delivery-id assigned by the session. The delivery-id is then used to refer to the delivery-tag in all subsequent interactions on that session.

For simplicity the delivery-id is omitted in the following diagrams and the delivery-tag is itself used directly. These diagrams also assume that this interaction takes place in the context of a single established link, and as such omit other details that would be present on the wire in practice such as the channel number, link handle, fragmentation flags, etc, focusing only on the essential aspects of message transfer.

Upon receiving the transfer, the receiving link endpoint (Receiver) will create an entry in its own unsettled map and make the transferred message data available to the application to process.

Once notified of the received message data, the application processes the message, indicating the updated delivery state to the link endpoint as desired. Applications may wish to classify delivery states as terminal or non-terminal depending on whether an endpoint will ever update the state further once it has been reached. In some cases (e.g. large messages or transactions), the receiving application may wish to indicate non-terminal delivery states to the sender. This is done via the frame.

Once the receiving application has finished processing the message, it indicates to the link endpoint a terminal delivery state that reflects the outcome of the application processing (successful or otherwise) and thus the outcome which the Receiver wishes to occur at the Sender. This state is communicated back to the Sender via the disposition frame.

Upon receiving the updated delivery state from the Receiver, the Sender will, if it has not already spontaneously attained a terminal state, update its view the state and communicate this back to the sending application.

The sending application will then typically perform some action based on this terminal state and then settle the delivery, causing the Sender to remove the delivery-tag from its unsettled map. The Sender will then send its final delivery state along with an indication that the delivery is settled at the Sender. Note that this amounts to the Sender announcing that it is forever forgetting everything about the delivery-tag in question, and as such it is only possible to make such an announcement once, since after the Sender forgets, it has no way of remembering to make the announcement again. Should this frame get lost due to an interruption in communication, the Receiver will find out that the Sender has settled the delivery upon link recovery. When the Sender re-attaches the Receiver will examine the unsettled state of the Sender (i.e. what has not been forgotten) and from this can derive that the delivery in question has been settled (since its tag will not be in the unsettled state).

When the Receiver finds out that the Sender has settled the delivery, the Receiver will update its view of the remote state to indicate this, and then notify the receiving application.

The application may then perform some final action, e.g. remove the delivery-tag from a set kept for de-duplication, and then notify the Receiver that the delivery is settled. The Receiver will then remove the delivery-tag from its unsettled map. Note that because the Receiver knows that the delivery is already settled at the Sender, it makes no effort to notify the other endpoint that it is settling the delivery.

As alluded to above, it is possible for the sending application to transition a delivery to a terminal state at the Sender spontaneously (i.e. not as a consequence of a disposition that has been received from the Receiver). In this case the Sender should send a disposition to the Receiver, but not settle until the Receiver confirms, via a disposition in the opposite direction, that it has updated the state at its endpoint.

This set of exchanges illustrates the basic principals of message transfer. While a delivery is unsettled the endpoints exchange the current state of the delivery. Eventually both endpoints reach a terminal state as indicated by the application. This triggers the other application to take some final action and settle the delivery, and once one endpoint settles, this usually triggers the application at the other endpoint to settle.

This basic pattern can be modified in a variety of ways to achieve different guarantees, for example if the sending application settles the delivery before sending it, this results in an at-most-once guarantee. The Sender has indicated up front with his initial transmission that he has forgotten everything about this delivery and will therefore make no further attempts to send it. Should this delivery make it to the Receiver, the Receiver clearly has no obligation to respond with updates of the Receiver's delivery state, as they would be meaningless and ignored by the Sender.

Similarly, if we modify the basic scenario such that the receiving application chooses to settle immediately upon processing the message rather than waiting for the sender to settle first, we get an at-least-once guarantee. If the disposition frame indicated below is lost, then upon link recovery the Sender will not see the delivery-tag in the Receiver's unsettled map and will therefore assume the delivery was lost and resend it, resulting in duplicate processing of the message at the Receiver.

As one might guess, the scenario presented initially where the sending application settles when the Receiver reaches a terminal state, and the receiving application settles when the Sender settles, results in an exactly-once guarantee. More generally if the Receiver settles prior to the Sender, it is possible for duplicate messages to occur, except in the case where the Sender settles before his initial transmission. Similarly, if the Sender settles before the Receiver reaches a terminal state, it is possible for messages to be lost.

The Sender and Receiver policy regarding settling may either be pre-configured for the entire link, thereby allowing for optimized endpoint choices, or may be determined on an ad-hoc basis for each delivery. An application may also choose to settle at an endpoint independently of its delivery state, for example the sending application may choose to settle a delivery due to the message ttl expiring regardless of whether the Receiver has reached a terminal state.

When a suspended link having unsettled deliveries is resumed, the unsettled field from the frame will carry the delivery-tags and delivery state of all deliveries considered unsettled by the issuing link endpoint. The set of delivery tags and delivery states contained in the unsettled maps from both endpoints can be divided into three categories:

Deliveries that only the Source considers unsettled

Deliveries in this category MAY be resumed at the discretion of the sending application. If the sending application marks the resend attempt as a resumed delivery then it MUST be ignored by the receiver. (This allows the sender to pipeline resumes without risk of duplication at the sender).

Deliveries that only the Target considers unsettled

Deliveries in this category MUST be ignored by the Sender, and MUST be considered settled by the Receiver.

Deliveries that both the Source and Target consider unsettled

Deliveries in this category MUST be resumed by the Sender.

Note that in the case where an endpoint indicates that the unsettled map is incomplete, the absence of an entry in the unsettled map is not an indication of settlement. In this case the two endpoints must reduce the levels of unsettled state as much as they can by the Sender resuming and/or settling transfers that it observes that the Receiver considers unsettled. Upon completion of this reduction of state, the two parties must suspend and re-attempt to resume the link. Only when both sides have complete unsettled maps may new unsettled state be created by the sending of non-resuming transfers.

A delivery is resumed much the same way it is initially transferred with the following exceptions:

• The resume flag of the frame MUST be set to true when resuming a delivery.

• The Sender MAY omit message data when the Delivery State of the Receiver indicates retransmission is unnecessary.

Note that unsettled delivery-tags do NOT have any valid delivery-ids associated until they are resumed, as the delivery-ids from their original link endpoints are meaningless to the new link endpoints.

Each frame may carry an arbitrary amount of message data up to the limit imposed by the maximum frame size. For Messages that are too large to fit within the maximum frame size, additional data may be transferred in additional frames by setting the more flag on all but the last frame. When a message is split up into multiple frames in this manner, messages being transferred along different links MAY be interleaved. However, messages transferred along a single link MUST NOT be interleaved.

The sender may indicate an aborted attempt to deliver a Message by setting the abort flag on the last . In this case the receiver MUST discard the Message data that was transferred prior to the abort.