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

Reduction of publication message size in a bandwidth-constrained publish/subscribe environment

IP.com Disclosure Number: IPCOM000015905D
Original Publication Date: 2002-Jun-16
Included in the Prior Art Database: 2003-Jun-21
Document File: 2 page(s) / 46K

Publishing Venue

IBM

Abstract

This invention relates to a publish/subscribe system which has a bandwidth-constrained link between a publishing client and the message broker. A specific example of this environment is SCADA (Supervisory, Control, And Data Acquisition) and Telemetry Integration systems. A "topic" string is used to describe what the message is "about". It is often the case, that a remote publishing client will regularly publish a message of the same "type". A good example is a remote telemetry publisher producing an hourly report which declares the current status of the remote equipment being monitored. In this case, the topic used for the publication would look something like (for example): Weather/London/HourlyStatus Every hour, the device would publish a report using this same topic. This is very wasteful of the expensive, constrained bandwidth over which such devices are typically connected (e.g. satellite links, GSM phones, etc), since the text of the topic would be transmitted each time.

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

Page 1 of 2

  Reduction of publication message size in a bandwidth-constrained publish/subscribe environment

This invention relates to a publish/subscribe system which has a bandwidth-constrained link between a publishing client and the message broker. A specific example of this environment is SCADA (Supervisory, Control, And Data Acquisition) and Telemetry Integration systems. A "topic" string is used to describe what the message is "about".

     It is often the case, that a remote publishing client will regularly publish a message of the same "type". A good example is a remote telemetry publisher producing an hourly report which declares the current status of the remote equipment being monitored. In this case, the topic used for the publication would look something like (for example):
Weather/London/HourlyStatus

     Every hour, the device would publish a report using this same topic. This is very wasteful of the expensive, constrained bandwidth over which such devices are typically connected (e.g. satellite links, GSM phones, etc), since the text of the topic would be transmitted each time.

     For example, for several Telemetry Integration projects, customers have adopted the convention:
project/location identifier/type of report/sub type
so, for example:
Weather/London/Temperature/maximum

     Note that there may be exceptional conditions, such as alerts, where a different topic has to be used to notify operators of an exceptional condition, e.g. Weather/London/ligtningAlert, or a message sent out to a paging gateway: pager/sms/0123456789.

     This problem is solved by introducing the concept of a "default topic". This is a topic which the broker will assign to the message in the event that the publisher does not supply one.

This can be implemented in a number of ways:
1) the publisher sends a special type of message, saying "from now on, if I don't specify a topic, please assume topic: x/y/z".
2) the publisher publishes a message to a topic, and sets a flag in the message header to say "Here's a regular publication on a given topic. Please remember this topic as my future default topic". This removes the need for an additional message to be sent, saving bandwidth. After this, the publisher can publish a message without a topic, and upon receipt of the message, the broker will modify the message to give it the previously declared default topic. If the message has a topic, then the default isn't applied and the given topic remains intact (e.g. for alert notifications).
3) the broker can be modified to enable this feature to be implemented without modification to the existing client APIs or wire formats: a mechanism is inserted at the point where the message enters the broker, which examines the topic in the received publication. If the topic has not been supplied by the publisher, then the mechanism inserts the previous topic that was used by that particular publishing client.

1

Page 2 of 2

     So the client would publish a message to a named topic. Then if the next and sub...