The Multicast Extension Swiftlet provides IP multicast for the publish/subscribe message domain between SwiftMQ routers. Multicast is an alternative to routing connections and makes SwiftMQ able to build up very large publish/subscribe domains with thousands of routers/clients.
Subnets may be set up with nearly an unlimited number of routers which exchange pub/sub messages via multicast, each router serving many JMS clients. There is no need to configure network routers to support multicast, because one SwiftMQ router can be configured as a gateway with a routing connection to another SwiftMQ router, residing in a different subnet. Thus, all multicast messages received within one subnet will be transferred from this gateway via a TCP routing connection to the gateway in another subnet which publishes it via multicast in that subnet.
JMS clients are connected to their local routers via normal TCP connections and, hence, have full JMS transactional capability including durable subscribers. This is a big advantage over so-called serverless JMS multicast implementations which are not able to provide JMS transactions or durable subscribers.
Because routers in a SwiftMQ multicast domain can have the same name, the Multicast Extension Swiftlet stores internal routing information about the requestor within the request by using vendor properties, prefixed with "JMS_SWIFTMQ_".
If a new message is created for the reply, these properties must be copied from the request into the new reply message like this:
// Receive the request
TextMessage request = (TextMessage)session.receive();
// Create the reply
TextMessage reply = session.createTextMessage();
// Copy the JMS_SWIFTMQ_ properties
for (Enumeration _enum = request.getPropertyNames(); _enum.hasMoreElements();)
{
String name = (String) _enum.nextElement();
if (name.startsWith("JMS_SWIFTMQ_"))
reply.setObjectProperty(name, request.getObjectProperty(name));
}
// Process the request, fill the reply
...
// Send the reply
session.publish((Topic)request.getJMSReplyTo(), reply);
There is nothing to do if the original request is used a reply.
After the deployment, define one or more multicast connections:
Every multicast connection is mapped to a particular multicast address, port, and an optional interface address which is specified if multiple network cards are used.
Now, define the topics you wish to map to this multicast connection:
You can specify every topic whether it should be sent over and/or received from this multicast connection. In the send case, a subscriber is created to this topic and received messages are then sent via this connection. In the receive case, a publisher is created to this topic and messages received from the multicast connection are published under that topic. Per default, publish/subscribe flow control is respected. So the publisher throttles to the slowest subscriber. If the receive rate of the multicast connection is higher, the LRMP protocol will adapt flow control as well, but only as to some ranges. It is not guaranteed that messages are not lost. Therefore, switch the flow control off if it doesn't fit your requirements.
You can easily bridge multicast connections, hence receive messages from one connection where the topic is marked as "receive" and send messages to another multicast connection where the same topic is marked as "send".
The Swiftlet sends statistic messages on every multicast connection if the statistic send interval is set higher than 0. A statistic message contains information about the message rates, the creation time of this connection etc. These statistics are displayed within the "Usage" folder of all other clients which share the same multicast address/port:
This is called the "neighbourhood". There is a time out for the neighbourhood after which an entry will be removed from that list. A statistic message wasn't received within this interval and the client is probably disconnected.