Page History

...

Protocol Header

The body segments of management QMF messages are composed of sequences of binary-encoded data fields, in a manner consistent with the 0-10 version of the AMQP specification.

All management QMF messages begin with a message header:

          octet 0      1         2         3         4         5         6         7
        +---------+---------+---------+---------+---------+---------+---------+---------+
        |   'A'   |   'M'   |   '12'   | op-code |                sequence               |
        +---------+---------+---------+---------+---------+---------+---------+---------+

The first three octets contain the protocol magic number "AM1AM2" which is used to identify the type and version of the message.

The opcode field identifies the operation represented by the message

Mapping QMF Messages to AMQP Messages

QMF messages are carried in the body segments of AMQP messages. An AMQP message body may contain 1 or more QMF messages. QMF messages do not span AMQP messages, each QMF messages must be entirely contained within a single AMQP message body.

Protocol Exchange Patterns

...

Manageable objects are tagged with a unique 64128-bit object identifier. The object identifier space is owned and managed by the management broker. Objects managed by a single management broker shall have unique object identifiers. Objects managed by separate management brokers may have the same object identifier.

If a management console is designed to manage multiple management brokers, it must use the broker identifier as well as the object identifier to ensure global uniqueness.

first uint64:
         63   6260 59              48 47                   28 27      24 23                    0
        +-------+------------------+-----------------------+-------------------------+
-----+
        |0 flags |     sequence  |   |      broker bank      |    |      agent bank object         |
        +-------+------------------+-----------------------+------------------------------+

second uint64:
       bit  63        - reserved, must be zero
                                   bits 63 .. 48  - broker boot sequence (32K)
        bits 47 .. 24  - bank (16M)
        bits 23 .. 0
   -    object (16M)

• For persistent IDs, boot-sequence is zero
• For non-persistent IDs, boot sequence is a constant number which increments each time the management broker is restarted.
• Bank number:
  • 0 - reserved
  • 1 - broker-persistent objects
  • 2..4 - store-persistent objects
  • > 4 - transient objects

Establishing Communication Between Client and Agent

Communication is established between the management client and management agent using normal AMQP procedures. The client creates a connection to the broker and then establishes a session with its corresponding channel.

Two private queues are then declared (only one if method invocation is not needed). A management queue is declared and bound to the qpid.management exchange. If the binding key is "mgmt.#", all management-related messages sent to the exchange will be received by this client. A more specific binding key will result in a more restricted set of messages being received (see the section on Routing Key Structure below).

If methods are going to be invoked on managed objects, a second private queue must be declared so the client can receive method replies. This queue is bound to the amq.direct exchange using a routing key equal to the name of the queue.

When a client successfully binds to the qpid.management exchange, the management agent schedules a schema broadcast to be sent to the exchange. The agent will publish, via the exchange, a description of the schema for all manageable objects in its control.

 +---------------------------------------------------------------------------------+
        |        Client                             object                             Broker
        |                                                               |
        | +----- AMQP Connection and Session Setup -----------------------------> |
        |                                                               |
        | --- Queue.declare (private data queue) ---------------------> |
        | --- Bind queue to exchange 'qpid.management' key 'mgmt.#' --> |
        |                                                               |
        | --- Queue.declare (private method-reply queue) --------------------+

• For persistent IDs, sequence is zero
• For non-persistent IDs, sequence is a number which increments each time the management broker is restarted.

Establishing Communication Between Client and Agent

Communication is established between the management client and management agent using normal AMQP procedures. The client creates a connection to the broker and then establishes a session with its corresponding channel.

A private (exclusive/auto-delete) queue is then declared and bound to the qpid.management exchange. A binding with key "schema.#" will subscribe to all schema-related information and a second binding with key "console.#" will subscribe to all management data.

A binding must also be established to the "amq.direct" exchange using the queue's name as the binding key. This will be used as a reply-to address for requests sent to the broker and to agents.

When a client successfully binds to the qpid.management exchange, the management agent schedules a schema broadcast to be sent to the exchange. The agent will publish, via the exchange, a description of the schema for all manageable objects in its control.

      Client         > |
        | --- Bind queue to exchange 'amq.direct' --------------------> |
        |                                                               |
        | --- Broker Request -----------------------------------------> |
        | <---------------------------------------- Broker Response --- |
        |                                            Broker
        |           |
        |                                               |
        | --- AMQP Connection and Session Setup -------------------------> |
        |                                                                  |
        | <--- Queue.declare (private data queue) ------------------------> |
        | --- ManagementBind schemaqueue viato exchange 'qpid.management' key 'schema.#' ---> |
        | --- Bind queue to exchange 'qpid.management' key 'console.#' --> |
        | --- Bind queue to exchange 'amq.direct' -----------------------> |
        |                               |

Broadcast of Configuration and Instrumentation Updates

The management agent will periodically publish updates to the configuration and instrumentation of management objects under its control. Under normal circumstances, these updates are published only if they have changed since the last time they were published. Configuration updates are only published if configuration has changed and instrumentation updates are only published if instrumentation has changed. The exception to this rule is that after a management client binds to the qpid.management exchange, all configuration and instrumentation records are published as though they had changed whether or not they actually did.

         Client                          |
                                Broker
   | --- Broker Request --------------------------------------------> |
        | <------------------------------------------- Broker Response --- |
        |                                                  |
        | <------------------ Object properties via 'mgmt.*.prop.#' --- | |
        | <------------------ Object statistics via 'mgmt.*.stat.#' --- | |
        |                                                               | |
        |                                                               | | Publish Interval|
        | <---------- Management schema via exchange 'qpid.management' --- |
                                                       | |
        |                                                               |

Broadcast of Configuration and Instrumentation Updates

The management agent will periodically publish updates to the configuration and instrumentation of management objects under its control. Under normal circumstances, these updates are published only if they have changed since the last time they were published. Configuration updates are only published if configuration has changed and instrumentation updates are only published if instrumentation has changed. The exception to this rule is that after a management client binds to the qpid.management exchange, all configuration and instrumentation records are published as though they had changed whether or not they actually did.

  Client |
        |                                                               | V
    Broker
    | <------------------ Object properties via 'mgmt.*.prop.#' --- |
        | <------------------ Object statistics via 'mgmt.*.stat.#' --- |
        |                                                 |
    | <--- Object properties via 'console.obj.1.<agent-bank>.<package>.<class>' --- | |
    |

Invoking a Method on a Managed Object

When the management client wishes to invoke a method on a managed object, it sends a method request message to the qpid.management exchange. The routing key contains the object class and method name (refer to Routing Key Structure below). The method request must have a header entry (reply-to) that contains the name of the method-reply queue so that the method response can be properly routed back to the requestor.

The method request contains a sequence number that is copied to the method reply. This number is opaque to the management agent and may be used by the management client to correlate the reply to the request. The asynchronous nature of requests and replies allows any number of methods to be in-flight at a time. Note that there is no guarantee that methods will be replied to in the order in which they were requested.

 <--- Object statistics via 'console.obj.1.<agent-bank>.<package>.<class>' --- | |
    |                  Client                                                          Broker
   | |
    |                                                                |
        | --- Method Request (to exchange 'qpid.management') ---------> | | Publish
    |        |                                                                       | | Interval
    |    |                                                                    |
       | | <--------------- Method Reply (via exchange 'amq.direct') --- |

    |                |                                                               |

Messages for the Basic Scenario

The principals in a management exchange are the management client and the management agent. The management agent is integrated into the QPID broker and the management client is a remote entity. A management agent may be managed by zero or more management clients at any given time. Additionally, a management client may manage multiple management agents at the same time.

For authentication and access control, management relies on the mechanisms supplied by the AMQP protocol.

Basic Opcodes

Broker Request Message

When a management client first establishes contact with the broker, it sends a Hello message to initiate the exchange.

 V
    | <--- Object properties via 'console.obj.1.<agent-bank>.<package>.<class>' --- |
    | <--- Object statistics via 'console.obj.1.<agent-bank>.<package>.<class>' --- |
    |                                                                               |

Invoking a Method on a Managed Object

When the management client wishes to invoke a method on a managed object, it sends a method request message to the qpid.management exchange. The routing key contains the object class and method name (refer to Routing Key Structure below). The method request must have a header entry (reply-to) that contains the name of the method-reply queue so that the method response can be properly routed back to the requestor.

The method request contains a sequence number that is copied to the method reply. This number is opaque to the management agent and may be used by the management client to correlate the reply to the request. The asynchronous nature of requests and replies allows any number of methods to be in-flight at a time. Note that there is no guarantee that methods will be replied to in the order in which they were requested.

      Client        

        +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '1' | 'B' |           0           |
        +-----+-----+    Broker
        |                                                               |
        | --- Method Request (to exchange 'qpid.management') --------+-----+-----------------------+

The Broker Request message has no payload.

Broker Response Message

When the broker receives a Broker Request message, it responds with a Broker Response message. This message contains an identifier unique to the broker.

-> |
        |              +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '1' | 'b' |           0           |
        +-----+-----+-----+-----+-----------------------+----------------------------+   |
        |  brokerId (uuid)                                                            |
        +| <----------------------------------------------------------------------------+

Command Completion Message

 Method Reply (via exchange 'amq.direct') --- |
        |                   +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '1' | 'z' |          seq          |
        +-----+-----+-----+-----+-----------------------+
        |  Completion Code      |
        +-----------------------+-----------------------------------------+
        |  Completion Text                                                |
        +-----------------------------------------------------------------+

Class Query

        +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '1' | 'Q' |          seq          |
        +-----+-----+-----+-----+-----------------------+----------+
        |  package name (str8)                                     |
        +----------------------------------------------------------+

Class Indication

|

Details of QMF Message Types

Broker Request Message

When a management console first establishes contact with the broker, it sends a Broker Request message to initiate the exchange.

        routing_key: broker
        +-----+-----+

        +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '12' | 'qB' |           seq0           |
        +-----+-----+-----+-----+-----------------------+----------+
      

The Broker Request message has no payload.

Broker Response Message

When the broker receives a Broker Request message, it responds with a Broker Response message. This message contains an identifier unique to the broker.

    |  package name (str8)      routing_key: <reply_to                              |from request>
        +-----+-----+-----+-----+--------------------------------------+
        | 'A' class| name (str8)    'M' | '2' | 'b' |               0                    |
        +-----+-----+-----+-----+-----------------------+----------------+------------+
        |  schema hash (bin128) brokerId (uuid)                                                            |
        +----------------------------------------------------------------------------+

...

Command Completion Message

        routing_key: <reply_to from request>
        +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '12' | 'Sz' |          seq          |
        +-----+-----+-----+-----+----+-------------------+----------+
        |  Completion              packageName (str8Code (uint32)  |
                      |
        ++----------------------------+------------------------------------+
        |  Completion Text (str8)              className (str8)                          |
        +-----------------------------------------------------------------+

Class Query

        | routing_key: broker
        +-----+-----+-----+-----+-----------------------+
         schema-hash (bin128)  | 'A' | 'M' | '2' | 'Q' |          seq          |
        +-----+-----+-----+-----+-----------------------+---------------+

Schema Response

+
        |   +-----+-----+-----+-----+-----------------------+
package name (str8)         | 'A' | 'M' | '1' | 's' |          seq          |
        +-----+----------+-----+-----+-----------------------+----------+

Class Indication

        |         routing_key: <reply_to from request> (if in reply to a request)
       packageName (str8)             schema.package          (if |unsolicited)
        +-----+-----+-----+----------+---------------------------------+
        | 'A' | 'M' | '2' | 'q' |        className (str8) seq          |
        +-----+-----+-----+-----+---------------+-------+
        | class kind (uint8) 1=Object, 2=Event  |
        +----------------------------------------+------------------+
        | package name (str8)               schema-hash (bin128)                      |
        +------------+--------------+-----------+-----------+----------+
        | propCnt   | statCntclass name (str8)                                   | methodCnt | eventCnt  |
        +-----------+-----------+-----------+-----------+----------------------------+
        | propCntschema property records   hash (bin128)                                                |
        +---------------------------------------------------------------------+

Schema Request

-------+
        | statCnt statistic recordsrouting_key: broker
         +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '2' | 'S' |          seq                 |
        +-----+-----+-----+-----+-----------------------+---------------------------------+
        | methodCnt method recordspackageName (str8)                                                   |
        +----------------------------------------------------------------------------+
        | eventCntclassName event(str8) records                                                     |
        +----------------------------------------------------------+
        | schema-hash (bin128)                                     |
        +---------------------+

Each property record is an AMQP map with the following fields. Optional fields may optionally be omitted from the map.

Each statistic record is an AMQP map with the following fields:

method and event records contain a main map that describes the method or header followed by zero or more maps describing arguments. The main map contains the following fields:

Argument maps contain the following fields:

type codes are numerics with the following values:

access codes are numerics with the following values:

direction codes are numerics with the following values:

Heartbeat Indication

        +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '1' | 'h' |           0           |
        +-----+-----+-----+-----+-----------------------+
        | timestamp of current interval (datetime)      |
        +-----------------------------------------------+

Configuration and Instrumentation Content Messages

Content messages are published when changes are made to the values of properties or statistics or when new management clients bind a queue to the management exchange.

-------------------------------------+

Schema Response

        routing_key: <reply_to from request> (if in reply to a request)
                     schema.package          (if unsolicited)
        +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '2' | 's' |          seq          |
        +-----+-----+-----+-----+------------+----------+
        | kind (uint8) 1=Object, 2=Event     |
        +------------------------------------+---------------------+
        | packageName (str8)                                       |
        +----------------------------------------------------------+
        | className (str8)                                         |
        +----------------------------------------------------------+
        | schema-hash (bin128)                                     |
        +-----------------------------------------------+----------+
        | propCount (uint16)                            |
        +-----------------------------------------------+
        | statCount (uint16)                            |
        +-----------------------------------------------+
        | methodCount (uint16)                          |
        +-----------------------------------------------+----------------------------+
        | propCount property records                                                 |
        +----------------------------------------------------------------------------+
        | statCount statistic records                                                |
        +----------------------------------------------------------------------------+
        | methodCount method records                                                 |
        +----------------------------------------------------------------------------+

Each property record is an AMQP map with the following fields. Optional fields may optionally be omitted from the map.

Each statistic record is an AMQP map with the following fields:

method records contain a main map that describes the method or header followed by zero or more maps describing arguments. The main map contains the following fields:

Argument maps contain the following fields:

type codes are numerics with the following values:

access codes are numerics with the following values:

direction codes are strings with the following values:

Heartbeat Indication

        routing_key: console.heartbeat.1.<agent_bank>
        +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '2' | 'h' |           0           |
        +-----+-----+-----+-----+-----------------------+
        | timestamp of current interval (datetime)      |
        +-----------------------------------------------+

Configuration and Instrumentation Content Messages

Content messages are published when changes are made to the values of properties or statistics or when new management clients bind a queue to the management exchange.

        for 'g':     routing_key: <reply_to from request>
        for 'c','i': routing_key: console.obj.1.<agent_bank>.<package_name>.<class_name>
        +-----+-----+-----+-------+-----------------------+
        | 'A' | 'M' | '2' |'g/c/i'|          seq          |
        +-----+-----+-----+-------+-----------------------+--------+
        |                packageName (str8)                        |
        +----------------------------------------------------------+
        |                className (str8)                          |
        +----------------------------------------------------------+
        |                class hash (bin128)                       |
        +-----+-----+-----+-----+-----+-----+-----+-----+----------+
        | timestamp of current sample (datetime)        |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        | time object was created (datetime)            |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        | time object was deleted (datetime)            |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        | objectId (bin128)                             |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        | presence bitmasks (0 or more uint8 fields)    |
        +-----+-----+-----+-----+-----+-----+-----+-----+------------------------+
        | config/inst values (in schema order)                                   |
        +------------------------------------------------------------------------+

All timestamps are uint64 values representing nanoseconds since the epoch (January 1, 1970). The objectId is a bin128 value that uniquely identifies this object instance.

If any of the properties in the object are defined as optional, there will be 1 or more "presence bitmask" octets. There are as many octets as are needed to provide one bit per optional property. The bits are assigned to the optional properties in schema order (first octet first, lowest order bit first).

For example: If there are two optional properties in the schema called "option1" and "option2" (defined in that order), there will be one presence bitmask octet and the bits will be assigned as bit 0 controls option1 and bit 1 controls option2.

If the bit for a particular optional property is set (1), the property will be encoded normally in the "values" portion of the message. If the bit is clear (0), the property will be omitted from the list of encoded values and will be considered "NULL" or "not present".

The element values are encoded by their type into the message in the order in which they appeared in the schema message.

Event Indication Message

        routing_key: console.event.1.<agent_bank>.<package_name>.<event_name>

        +-----+-----+-----+-------+-----------------------+
        | 'A' | 'M' | '12' | 'g/c/ie' |          seq          |
        +-----+-----+-----+-----+--+---------------------+--+--------+
        | packageName (str8)              packageName (str8)                        |
        +----------------------------------------------------------+
        | eventName (str8)              className (str8)                          |
        +----------------------------------------------------------+
        | class hash (bin128)             class hash (bin128)                       |
        +----------+-------+-----+-----+-----+-----+-----+-----+----------+
        | timestamp of currentevent sample (datetime)                 |
        +-----+--------+-----+-----+-----+--------+-----+-----+
        | time object was created (datetimeseverity (uint8)      |
      |
        +  +-----------------------+-------+-----------+-----+-----+-----+-----+-----+-----+
        | timeevent argument objectvalues was(in deletedschema (datetime)order)                                |
        +-----+-------------------------------------+-----+-----+-----+-----+-----+-----+
        | objectId (uint64)      

Get Query Message

A Get Request may be sent by the management console to cause a management agent to immediately send content information for objects of a class.

                       |routing_key: agent.1.<agent_bank>
        +-----+-----+-----+-----+-----+--------+-----+-----+
        | presence bitmasks (0 or more uint8 fields)'A' | 'M' | '2' | 'G' |          seq          |
        +-----+-----+-----+-----+-----+-----+-----+-----+---+---------------------+
        | config/instGet valuesrequest (infield schematable order)     (map)                              |
        +------------------------------------------------------------------------+

All timestamps are uint64 values representing nanoseconds since the epoch (January 1, 1970). The objectId is a uint64 value that uniquely identifies this object instance.

If any of the properties in the object are defined as optional, there will be 1 or more "presence bitmask" octets. There are as many octets as are needed to provide one bit per optional property. The bits are assigned to the optional properties in schema order (first octet first, lowest order bit first).

For example: If there are two optional properties in the schema called "option1" and "option2" (defined in that order), there will be one presence bitmask octet and the bits will be assigned as bit 0 controls option1 and bit 1 controls option2.

If the bit for a particular optional property is set (1), the property will be encoded normally in the "values" portion of the message. If the bit is clear (0), the property will be omitted from the list of encoded values and will be considered "NULL" or "not present".

The element values are encoded by their type into the message in the order in which they appeared in the schema message.

Get Query Message

The content of a get request is a field table that specifies what objects are being requested. Most of the fields are optional and are available for use in more extensive deployments.

When the management agent receives a get request, it sends content messages describing the requested objects. Once the last content message is sent, it then sends a Command Completion message with the same sequence number supplied in the request to indicate to the requestor that there are no more messages coming.

Method Request

Method request messages have the following structure. The sequence number is opaque to the management agent. It is returned unchanged in the method reply so the calling client can correctly associate the reply to the request. The objectId is the unique ID of the object on which the method is to be executedA Get Request may be sent by the management console to cause a management agent to immediately send content information for objects of a class.

        +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '1' | 'G' |          seq          |routing_key: agent.1.<agent_bank>
        +-----+-----+-----+-----+-----+-----+-------------+----------+
        | Get'A' request| field'M' table| '2' | 'M' |            seq                  |
        +----------------------------------------------------------+

The content of a get request is a field table that specifies what objects are being requested. Most of the fields are optional and are available for use in more extensive deployments.

When the management agent receives a get request, it sends content messages describing the requested objects. Once the last content message is sent, it then sends a Command Completion message with the same sequence number supplied in the request to indicate to the requestor that there are no more messages coming.

Method Request

Method request messages have the following structure. The sequence number is opaque to the management agent. It is returned unchanged in the method reply so the calling client can correctly associate the reply to the request. The objectId is the unique ID of the object on which the method is to be executed.

+-----+-----+-----+-----------------------+
        |  objectId (bin128)                            |
        +-----+---------+-----+-----+-----------------------+
        | 'A' | 'M' | '1' | 'M' |  package name (str8)                          |
        +-----------------------------------------------+
        |  class name (str8)                  seq          |
        +------+--------+-----+-----+-----------------------+
        |  objectIdclass hash (uint64bin128)                            |
        +-----------------------------------------------+
        |  methodName (str8)                            |
        +-----------------------------------------------+------------------------+
        |  input and bidirectional argument values (in schema order)             |
        +------------------------------------------------------------------------+

...

Method reply messages have the following structure. The sequence number is identical to that supplied in the method request. The status code (and text) indicate whether or not the method was successful and if not, what the error was. Output and bidirectional arguments are only included if the status code was 0 (STATUS_OK).

        routing_key: <reply_to from request>
        +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '12' | 'm' |          seq          |
        +-----+-----+-----+-----+-----------------------+
        |  status code          (uint32) |
        +-----------------------+----------------------------------+
        |  status text (str8str16)                                      |
        +-----------------------+----------------------------------+-------------+
        |  output and bidirectional argument values (in schema order)            |
        +------------------------------------------------------------------------+

status code values are:

Messages for Extended Scenario

...

      Broker                                                       Remote Agent
        |                                                               |
        | <----------------------------------------- Attach Request --- |
        | --- Attach Response ----------------------------------------> |
        |                                                               |
        | <------------------------------------- Package Indication --- |
        | <------------------------------------- Package Indication --- |
        |                                                               |
        | <--------------------------------------- Class Indication --- |
        | <--------------------------------------- Class Indication --- |
        | <--------------------------------------- Class Indication --- |
        | <--------------------------------------- Class Indication --- |
        | <--------------------------------------- Class Indication --- |
        |                                                               |
        | --- Schema Request (class key) -----------------------------> |
        | <---------------------------------------- Schema Response --- |
        |                                                               |
        | --- Schema Request (class key) -----------------------------> |
        | <---------------------------------------- Schema Response --- |
        |                                                               |
        |                                                               |

Extended Opcodes

...

opcode

...

message

...

description

...

'P'

...

Package Query

...

This message contains a schema package query request, requesting that the broker dump the list of known packages

...

'p'

...

Package Indication

...

This message contains a schema package indication, identifying a package known by the broker

...

'A'

...

Agent Attach Request

...

This message is sent by a remote agent when it wishes to attach to a management broker

...

'a'

...

Agent Attach Response

...

The management broker sends this response if an attaching remote agent is permitted to join

...

'x'

...

Console Added Indication

...

                  |

Package Query

        routing_key: agent.1.<agent_bank>
        +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '12' | 'P' |          seq          |
        +-----+-----+-----+-----+-----------------------------+

Package Indication

--------+

Package Indication

        routing_key: <reply_to from request> (if in reply to a request)
                     schema.package          (if unsolicited)

        +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '12' | 'p' |          seq          |
        +-----+-----+-----+-----+-----------------------+----------+
        |  package name (str8)                                     |
        +----------------------------------------------------------+

Agent Attach Request

        routing_key: broker
        +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '12' | 'A' |          seq          |
        +-----+-----+-----+-----+-----------------------+----------+
        |  label (str8)                                            |
        +------------------------+----------------------------------+
        |  system-id (uuid)                                        |
        +---------------------------------+------------------------+
        |  requested broker bank (uint32)  |
        +-----------------------+----------------------------------+
        |  requested objIdagent bank (uint32)  |
        +---------------------------------+

Agent Attach Response (success)

        routing_key: <reply_to from request>
        +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '12' | 'a' |          seq          |
        +-----+-----+-----+-----+--------+---------------+
        |  assigned broker bank (uint32) |
        +--------------------------------+
        |  assigned objIdagent bank (uint32)  |
        +--------------------------------+

Console Added Indication

        routing_key: agent.1.<agent_bank>
        +-----+-----+-----+-----+-----------------------+
        | 'A' | 'M' | '12' | 'x' |          seq          |
        +-----+-----+-----+-----+-----------------------+