You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

WIP

This page is still very much Work In Progress. It should be consider a draft.


Introduction

This page describes the design of a "Link Registry". This refers to "Links" as defined by the AMQP 1.0 specification.

There are a couple of situations in which the broker needs to quickly look up links.

  • When Attaching a Link the uniqueness of the ordered tuple (source-container-id, target-container-id, link-name) must be ensured.
  • When Attaching with a "null" Source or Target the existing Terminus should be easily recovered from the Link name.
  • When resuming a Link.

For this and other purposes the creation of a "Link Registry" is proposed.

Terminology and Responsibilities

The following is all extracted from the AMQP 1.0 specification. Where they disagree the specification is obviously the authoritative source.

  • between a source and a target
  • linkname enough to recover link (2.6.1.)
  • tuple (sourceContainerId, targetContainerId, linkName) MUST be globally unique. => only active on one connection
  • can be stolen by sending second Attach while not suspended (2.6.1)

Terminus (source or target)

  • keep track of "unsettled" delivery-tags & delivery-state
  • source assigns unique "delivery-tag" to delivery attempt
  • can exist without link endpoint ("suspended link")
  • termini can be assosiated with new endpoints ("resuming link")
  • has duribility 0 (no state), 1 (config), 2 (config + unsettled durable messages)

Link Endpoints (sender or receiver)

  • Interface between terminus and session endpoint
  • maintains additional state 
  • endpoint assigns unique delivery-id to message. (alias for delivery-tag?). this loses meaning (becomes invalid) when resuming a link because it is a new link endpoint
  • no state in the endpoint required to resume a link. this comes from the terminus
  • has "handle" to identify the link on the wire (alias). assigned by Attach. local handle = output handle; remote handle = input handle
  • "attached" if has both handles, otherwise "detached" or "half detached"

Session Endpoint

  • We call this Session_1_0
  • mapping between channel
  • must detach link if terminus is not created/found upon Attach (rejecting link)

Further Considerations

Thread Safety

The Link Registry will be used across multiple connections and thus has to be thread-safe!

Input Validation

The Link Registry will use user supplied values (link names, container ids). This information can come from both the config and over the wire. We have to make sure we validate both.

Specification Compliance

There are a couple of related sections in the AMQP 1.0 specification that we have to adhere to:

  • receiver must discard messages if considered settled and resumed delivery flag set
  • receiver must consider that the sender considers settled as settled
  • it is possible that resuming does not succeeds due to incomplete unsettled maps (2.6.13.)
  • when resuming a link we must include the unsettled state
  • must be able to do null-source lookup (null-target lookup?)

Requirements

  • recover link from tuple (sourceContainerId, targetContainerId, linkName)
  • recover unsettled state
  • high frequency & low latency update of unsettled state (JSON fail!)
  • handle different DeliveryStates (AMQP 1.0 section 3.4)

Design

  • Both Sessions and Links are abstract immaterial concepts. The concrete objects are the SessionEndpoints and the LinkEndpoints.
    For Sessions we already only have one object (called Session_1_0 to be aligned to the legacy protocols but this really is the SessionEndpoint).
    We should do the same for Link/-Endpoints and  get rid of one of them. Currently the responsibilities are very unclear and there seems to be no value.
  • As is currently the case each VirtualHost should have its own registry.
  • The implementation of the registry should be hidden behind an API so for example we do not care whether sending links and receiving links are maintained in the same data structure or in separate data structures.
  • A registry should support different levels of capability in alignment with the TerminusDurability.
    For example a Memory VH should not advertise any TerminusDurability, a JSON VirtualHost might be able to persist the configuration but not the settled state, while a BDB VH might support all three terminus durability modes.
  • Given the remote container id and the link name a lookup should return a Terminus so that a LinkEndpoint (and thus a Link) can be recreated dynamically.

 

 

  • No labels