Multicast topic topology issues
Use these examples to understand why certain IBM MQ Multicast topic topologies are not recommended.
As was mentioned in IBM MQ Multicast topic topology, IBM MQ Multicast support requires that each subtree has its own multicast group and data stream within the total hierarchy. Do not use a different multicast group address for a subtree and its parent.
The classful network IP addressing scheme has designated address space for multicast address. The full multicast range of IP address is 224.0.0.0 to 239.255.255.255, but some of these addresses are reserved. For a list of reserved address either contact the system administrator or see https://www.iana.org/assignments/multicast-addresses for more information. It is recommended that we use the locally scoped multicast address in the range of 239.0.0.0 to 239.255.255.255.
Recommended multicast topic topology
This example is the same as the one from IBM MQ Multicast topic topology, and shows 2 possible multicast data streams. Although it is a simple representation, it demonstrates the kind of situation that IBM MQ Multicast was designed for, and is shown here to contrast the second example:DEF COMMINFO(MC1) GRPADDR( 227.20.133.1) DEF COMMINFO(MC2) GRPADDR(227.20.133.2)where 227.20.133.1 and 227.20.133.2 are valid multicast addresses. These topic definitions are used to create a topic tree as shown in the following diagram:
DEFINE TOPIC(FRUIT) TOPICSTRING('Price/FRUIT') MCAST(ENABLED) COMMINFO(MC1)
DEFINE TOPIC(FISH) TOPICSTRING('Price/FISH') MCAST(ENABLED) COMMINFO(MC2)
Each multicast communication information (COMMINFO) object represents a different stream of data because their group addresses are different. In this example, the topic FRUIT is defined to use COMMINFO object MC1 , and the topic FISH is defined to use COMMINFO object MC2 .
IBM MQ Multicast has a 255 character limit for topic strings. This limitation means that care must be taken with the names of nodes and leaf-nodes within the tree; if the names of nodes and leaf-nodes are too long, the topic string might exceed 255 characters and return the MQRC_TOPIC_STRING_ERROR reason code.
Non-recommended multicast topic topology
This example extends the previous example by adding another topic object called ORANGES which is defined to use another COMMINFO object definition ( MC3 ):
DEF COMMINFO(MC1) GRPADDR(227.20.133.1 ) DEF COMMINFO(MC2) GRPADDR(227.20.133.2) DEF COMMINFO(MC3) GRPADDR(227.20.133.3)where 227.20.133.1, 227.20.133.2, and 227.20.133.3 are valid multicast addresses. These topic definitions are used to create a topic tree as shown in the following diagram:
DEFINE TOPIC(FRUIT) TOPICSTRING('Price/FRUIT') MCAST(ENABLED) COMMINFO(MC1)
DEFINE TOPIC(FISH) TOPICSTRING('Price/FISH') MCAST(ENABLED) COMMINFO(MC2)
DEFINE TOPIC(ORANGES) TOPICSTRING('Price/FRUIT/ORANGES') MCAST(ENABLED) COMMINFO(MC3)
While this kind of multicast topology is possible to create, it is not recommended because applications might not receive the data that they were expecting.
An application subscribing on 'Price/FRUIT/#' receives multicast transmission on the COMMINFO MC1 group address. The application expects to receive publications on all topics at or below that point in the topic tree.
However, the messages created by an application publishing on 'Price/FRUIT/ORANGES/Small' are not received by the subscriber because the messages are sent on the group address of COMMINFO MC3.
Parent topic: Multicast troubleshooting