Universal Messaging's ability to provide 'ultra-low latency' messaging has been further developed with the introduction of multicast options in addition to unicast to distribute messages to client applications.

This section assumes the reader has some knowledge of IP Multicast.

Universal Messaging delivers 'ultra-low latency' to a large number of connected clients by including IP Multicast functionality for both the delivery of events to Data Group consumers as well as between inter-connected realms within a Universal Messaging cluster.

With unicast, the server must physically write the message once for each destination client:

With multicast, a message is written to the network once where it is then routed to all connections in that multicast group:

Multicast has clear performance improvements in terms of scalability. Where the performance of unicast gradually degrades as the number of destinations increases, multicast performance does not as the server still only has to write a message once per destination.

Universal Messaging supports multicast for cluster communication and can be enabled on individual data groups. Universal Messaging will then transparently operate in a multicast delivery mode for clients on networks capable of supporting the multicast protocol else continue to use unicast.

When you create a data group you can pass a flag to enable multicast delivery. The Universal Messaging realm will automatically begin delivering events published to that group via multicast. When a client data stream is added to a multicast enabled data group, it will transparently receive the information it needs to begin consuming via multicast. Multicast delivery may not be possible for all clients so initially the client will be sent events via both unicast and multicast. The user will only be delivered the data once however.

The Universal Messaging server will quickly detect whether or not the multicast packets are reaching the client as it does or does not receive acknowledgements. If the client does not support multicast, the server will simply continue to send events to that client via unicast. If the multicast packets do reach the client then after a period of time when both unicast and multicast are in sync, the Universal Messaging Server will stop sending unicast events to that data stream.

Multicast addresses packets using the User Datagram Protocol (UDP) as opposed to TCP which is used in unicast. UDP is a connectionless protocol and does therefore not guarantee delivery or packet ordering in way that TCP does. However Universal Messaging still provides these guarantees by implementing the required checks at the application layer. These checks happen completely transparently to the user and any packet retransmissions can be monitored using the nAdminAPI or the Enterprise Manager.

Each Universal Messaging interface that you configure on a Universal Messaging Realm binds to one or all of the available physical Network adapters present on the host machine. In order to successfully configure Multicast on a Universal Messaging Realm you must ensure that you know the IP addresses of each of these network adapters (including virtual addresses if running on a virtual host), and which physical network adapter and its address is capable of supporting IP Multicast. This information allows the correct network adapter to be selected and bound to by the Multicast configuration. Once this information is known, you then need to ensure that the physical network infrastructure including switches and routers can support Multicast. Once validated, the next step is to select an available Multicast address which can be used.

Universal Messaging servers can use IP Multicast either to deliver Data Group events to its consumers or between Universal Messaging realms within a cluster. If you wish to enable IP Multicast delivery to Data Group consumers, you can create a Multicast configuration and select it for use with Data Groups. Once you have configured a Multicast adapter, when you create a Data Group with the enable Multicast flag set, the Universal Messaging realm will automatically begin delivering the events via Multicast when published to that Data Group. The client application requires no extra setup to begin receiving Multicast. When a client Data Stream is added to a Multicast enabled Data Group, the client will transparently receive the information it needs to begin consuming Multicast for that Data Group. The client will at first both consume the Unicast Data Group events, and if Multicast is possible, also consume the Multicast events. When both Unicast and Multicast are in sync after a period of time, the Universal Messaging Server will stop sending Unicast events for that Data Stream to the client. The Universal Messaging server will track whether each client is in fact able to process the Multicast packets and if any client does not successfully acknowledge safe receipt of the Multicast events, it will simply continue to consume the Unicast events.

With this model, the client is able to seamlessly interact with the Universal Messaging server and begin consuming Multicast events with no changes to the Client application required.