Design notes for AMQP 0-9 implemenation

  • Reserved field in Request frame must be set to 0.
  • Request and Response constants were added to amqp.0-9.xml
  • Request ID and Response ID must start at 1 for new channels. 0 is reserved for future use, and should not be used in normal interactions between client and server.
  • Response Mark must start at 0 for new channels.
  • Content class encoding: For inline messages (first byte = 0), a null or empty byte array may be used.
  • Content class encoding: For refs, (first byte = 1), an error or exception must be thrown if the byte array is either null or empty. It makes no sense to send a null ref.
  • Content class decoding: For inline messages (first byte = 0), is is not possible to discriminate between the null array or empty array case above that encoded it. Decode as an empty byte array, not a null. (open for discussion)
  • Content class: It may be possible to set a value for either/or null and empty values in the future - if a use-case can be made for it
  • Possible batch-handling modes should be decided upon.
  • TODO: Devise a mechanism to allow one-way requests, where no acknowledgements are sent.

AMQP 0-9 Specification Issues

  • Errara will be made by adding to an amqp-errata.0-9.xml file rather than by making edits directly to the specification file. These are the advantages:
    • The differences between the current specification and the spec as we use it are readily apparent.
    • Different implementations share the same specification file. Thus errors that may arise as a result of a change required for one implementation (e.g. Java) on others (e.g. C++) are controled/eliminated.
  • Two constants are missing and need to be inserted as an erratum: 
     <constant name = "frame-request"    value = "9" />
 <constant name = "frame-response"   value = "10" />
  • The Basic field Basic.type (a shortstr) was omitted from Message.transfer. However, after some discussion it was resolved that since thid field serves JMS messaging only, that it should be handled as a custom property rather than creating an XML erratum to insert it. The property name is "JMSXType".
  • The Basic field Basic.mandatory(a bit) was originally omitted form Message.transfer because its functionality would have been handled by the availability of dead-letter queues. However, they did not make it into the AMQP 0-9 speicification. Thus, Basic.mandatory has been temporarily added as the last field in Message.transfer until dead-letter queues become a reality in the specification.
  • No labels