Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Message Broker Use of Identifiers to Distinguish Neighbours

IP.com Disclosure Number: IPCOM000013391D
Original Publication Date: 1999-Oct-01
Included in the Prior Art Database: 2003-Jun-18
Document File: 2 page(s) / 30K

Publishing Venue

IBM

Related People

Simon Holdsworth: AUTHOR [+2]

Abstract

Within a multi-broker network, it is necessary for a broker to know the source of messages it receives in order to avoid loops by sending a message back to its source. This could be solved by having a broker insert its identity into each message which it sends to a neighbouring broker, however this has the disadvantage that it may result in the entire message being rewritten (inefficient for large messages) and requires the broker to have special case code when delivering messages to other brokers. Within a publish/subscribe system, it is often possible for a subscriber to specify an identifier which the broker must place in any messages sent to the client, in order for the client to distinguish messages sent to it from messages sent on the same transport link, but intended for other subscribers. The normal mode is thus for the subscriber to register with its own identity, which the broker then places in messages sent to that subscriber. For example, IBM's MQSeries has a correlation identifier in all message headers. This can be modified by the broker without having to rewrite the message content. The system described uses this mechanism, but with the key point that a broker assigns identifiers to its neighbours, so that each neighbour has a different identifier (two different brokers may represent the same, third broker using different identifiers), and registers with each neighbour using the neighbours identifier, rather than its own. When the neighbour sends messages to the broker, it naturally places the identifier supplied by the broker into the message. In this way the subscribing broker receives messages from each neighbour with that neighbour's identifier, without the neighbour being aware that it is sending the message to a broker, and without the neighbour needing to know the value of its identifier for the broker. The disclosure allows a multi-broker design where brokers do not need to have special case code for forwarding messages to other brokers. It also means that messages destined for other brokers do not have to be modified, other than a header field change. Both of these result in a more efficient broker.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Message Broker Use of Identifiers to Distinguish Neighbours

Within a multi-broker network, it is necessary for a broker to know the source
of messages it receives in order to avoid loops by sending a message back to
its source. This could be solved by having a broker insert its identity into
each message which it sends to a neighbouring broker, however this has the
disadvantage that it may result in the entire message being rewritten
(inefficient for large messages) and requires the broker to have special case
code when delivering messages to other brokers.

     Within a publish/subscribe system, it is often
possible for a subscriber to specify an identifier which
the broker must place in any messages sent to the client,
in order for the client to distinguish messages sent to it
from messages sent on the same transport link, but
intended for other subscribers. The normal mode is thus
for the subscriber to register with its own identity,
which the broker then places in messages sent to that
subscriber. For example, IBM's MQSeries has a correlation
identifier in all message headers. This can be modified
by the broker without having to rewrite the message
content.

     The system described uses this mechanism, but with
the key point that a broker assigns identifiers to its
neighbours, so that each neighbour has a different
identifier (two different brokers may represent the same,
third broker using different identifiers), and registers
with each neighbour using the neighbours identifier,
rather than its own. When the neighbour sends messages to
the broker, it naturally places the identifier supplied by
the broker into the message.

     In this way the subscribing broker receives messages
from each neighbour with that neighbour's identifier,
without the neighbour being aware that it is sending the
message to a broker, and without the neighbour needing to
know the value of its identifier for the broker. The
disclosure allows a multi-broker design where brokers do
not need to have special case code for forwarding messages
to other brokers. It also means that messages destined
for...