A UM application can function either as a source or a receiver. A source application sends messages, and a receiver application receives them. (It is also common for an application to function as both source and receiver; we separate the concepts for organizational purposes.)
This section discusses the following concepts.
UM offers the Publish/Subscribe model for messaging ("Pub/Sub"), whereby one or more receiver programs express interest in a topic, and one or more source programs send to that topic. So, a topic can be thought of as a data stream that can have multiple producers and multiple consumers. One of the functions of the messaging layer is to make sure that all messages sent to a given topic are distributed to all receivers listening to that topic. UM does this through an automatic process known as topic resolution.
A topic is just an arbitrary string. For example:
| Deals |
| Market/US/DJIA/Sym1 |
It is not unusual for an application system to have many thousands of topics, perhaps even more than a million, with each one carrying a very specific range of information (e.g. quotes for a single stock symbol).
It is also possible to configure receiving programs to match multiple topics using wildcards. UM uses powerful regular expression pattern matching to allow applications to match topics in a very flexible way. At the present time, messages cannot be sent to wildcarded topic names. See Wildcard Receiver.
UMP - which contains the Ultra Messaging® Streaming Edition (UMS) functionality - includes a component known as the persistent store, which provides stable storage (disk or memory) of message streams. UMP delivers a persisted message stream to receiving applications with no additional latency in the vast majority of cases. This offers the functionality of durable subscriptions and confirmed message delivery. Ultra Messaging streaming applications build and run with the UMP persistence feature without modification. See The Ultra Messaging Guide for Persistence and Queuing for more information.
UMQ - which contains both the Ultra Messaging Streaming Edition (UMS) functionality and the Ultra Messaging Persistence Edition (UMP) functionality - includes message queuing capabilities that allows sources to submit messages asynchronously to a queue and permits receivers to retrieve messages from a queue in an entirely different asynchronous manner. UMQ also supports Once and Only Once (OAOO) delivery and Application Sets that allow you to load balance processing or support multiple processing purposes for single topics. See The Ultra Messaging Guide for Persistence and Queuing for more information.
In many applications, a new receiver may be interested in messages that were sent before it existed. UM provides a late join feature that allows a new receiver to join a group of others already listening to a source. Without the late join feature, the joining receiver would only receive messages sent after the time it joined. With late join, the source stores sent messages according to its Late Join configuration options so a joining receiver can receive any of these messages that were sent before it joined the group. See Using Late Join.
UM also offers a Request/Response messaging model. A sending application (the requester) sends a message to a topic. Every receiving application listening to that topic gets a copy of the request. One or more of those receiving applications (responder) can then send one or more responses back to the original requester. UM sends the request message via the normal pub/sub method, whereas UM delivers the response message directly to the requester.
An important aspect of UM's Request/Response model is that it allows the application to keep track of which request corresponds to a given response. Due to the asynchronous nature of UM requests, any number of requests can be outstanding, and as the responses come in, they can be matched to their corresponding requests.
Request/Response can be used in many ways and is often used during the initialization of UM receiver objects. When an application starts a receiver, it can issue a request on the topic the receiver is interested in. Source objects for the topic can respond and begin publishing data. This method prevents the UM source objects from publishing to a topic without subscribers.
Be careful not to be confused with the sending/receiving terminology. Any application can send a request, including one that creates and manages UM receiver objects. And any application can receive and respond to a request, including one that creates and manages UM source objects.
A source application uses an UMS transport to send messages to a receiver application. A UM transport is built on top of a standard IP protocol. The different UM transport types have different tradeoffs in terms of latency, scalability, throughput, bandwidth sharing, and flexibility. The sending application chooses the transport type that is most appropriate for the data being sent, at the topic level. A programmer might choose different transport types for different topics within the same application.
A UM sending application can make use of very many topics (over a million). UM maps those topics onto a much smaller number of transport sessions. A transport session can be thought of as a specific instance of a transport type. A given transport session might carry a single topic, or might carry hundreds of thousands of topics. A receiving application may express interest in a small set of those topics, in which case UM will join the transport session, receiving messages for all topics carried on that transport session. UM will then discard any messages for topics that the application is not interested in. This user-space filtering does consume system resources (primarily CPU and bandwidth), and can be minimized by carefully mapping topics onto transport sessions according to receiving application interest.
Note: Non-multicast UM transport types can also use source-side filtering to decrease user-space filtering on the receiving side by doing the filtering on the sending side. However, while this might sound attractive at first glance, be aware that system resources consumed on the source side affect all receivers, and that the filtering for multiple receivers must be done serially, whereas letting the receivers do the filtering allows that filtering to be done in parallel, only affecting those receivers that need the filtering.
See Transport Objects.
Part of UM's design is a single threaded model for message data delivery which reduces latency in the receiving CPU. UM, however, also has the ability to distribute data delivery across multiple CPUs by using a receiving thread pool. Receivers created with the configuration option, use_transport_thread set to 1 use a thread from the thread pool instead of the context thread. The option, receive_thread_pool_size controls the pool size.
As receivers discover new sources through Topic Resolution, UM assigns the network sockets created for the receivers to receive data to either the context thread (default) or to a thread from the pool if use_transport_thread is set for the receiver. It is important to understand that thread assignment occurs at the socket level - not the transport level. Transports aggregated on to the same network socket use the same thread.
UM distributes data from different sockets to different threads allowing better process distribution and higher aggregate throughput. Distributing transports across threads also ensures that activity on each transport has no impact on transports assigned to other threads leading to lower latencies in some traffic patterns, e.g. heavy loss conditions.
The following lists restrictions to using multi-transport threads.
Only LBT-RM, LBT-RU, TCP and TCP-LB transport types may be distributed to threads.
Multi-Transport threads are not supported under sequential mode.
UM processes sources using the same transport socket, e.g. multicast address and port, on the same thread (regardless of the use_transport_thread setting. To leverage threading of different sources, assign each source to a different transport destination, e.g. multicast address/port.
Hot failover sources using LBT-RM on the same topic must not be distributed across threads because they must share the same multicast address and port.
Hot failover sources using other transport types may not be distributed across threads and must use the context thread.
Each transport thread has its own Unicast Listener (request) port. Ultra Messaging recommends that you expand the range request_tcp_port_low - request_tcp_port_high to a larger range when using transport threads. When late join is occurring, UM creates a TCP connection from the transport thread to the source.
Multi-transport threads are not recommended for use over the UM Gateway.
Multi-Transport Threads do not support persistent stores (UMP) or persistent receivers
Multi-Transport Threads do not support queues (UMQ) or queing receivers.
Multi-Transport Threads are not compatible with UMDS Server or UMCache
There are many different events that UM may want to deliver to the application. Many events carry data with them (e.g. received messages); some do not (e.g. end-of-stream events). Some examples of UM events:
A received message on a topic that the application has expressed interest in.
A timer expiring. Applications can schedule timers to expire in a desired number of milliseconds (although the OS may not deliver them with millisecond precision).
An application-managed file descriptor event. The application can register its own file descriptors with UM to be monitored for state changes (readable, writable, error, etc).
New source notification. UM can inform the application when sources are discovered by topic resolution.
Receiver loss. UM can inform the application when a data gap is detected that could not be recovered through the normal retransmission mechanism.
End of Stream. UM can inform a receiving application when a data stream (transport session) has terminated.
UM delivers events to the application by callbacks. The application explicitly gives UM a pointer to one of its functions to be the handler for a
particular event, and UM calls that function to deliver the
event, passing it the parameters that the application requires to process the event. In
particular, the last parameter of each callback type is a client
data pointer (clientdp). This pointer can be used at
the application's discretion for any purpose. It's value is specified by the application
when the callback function is identified to UM (typically when
UM objects are created), and that same value is passed back to
the application when the callback function is called.
There are two methods that UM can use to call the application callbacks: through context thread callback, or event queue dispatch.
In the context thread callback method (sometimes called direct callback), the UM context thread calls the application function directly. This offers the lowest latency, but imposes significant restrictions on the application function. See Event Queue Object.
The event queue dispatch of application callback introduces a dynamic buffer into which the UM context thread writes events. The application then uses a thread of its own to dispatch the buffered events. Thus, the application callback functions are called from the application thread, not directly from the context thread.
With event queue dispatching, the use of the application thread to make the callback allows the application function to make full, unrestricted use of the UM API. It also allows parallel execution of UM processing and application processing, which can significantly improve throughput on multi-processor hardware. The dynamic buffering provides resilience between the rate of event generation and the rate of event consumption (e.g. message arrival rate v.s. message processing rate).
In addition, an UM event queue allows the application to be warned when the queue exceeds a threshold of event count or event latency. This allows the application to take corrective action if it is running too slow, such as throwing away all events older than a threshold, or all events that are below a given priority.
For UDP-based transports (LBT-RU and LBT-RM), UM network stability is insured through the use of rate controls. Without rate controls, sources can send UDP data so fast that the network can be flooded. Using rate controls, the source's bandwidth usage is limited. If the source attempts to exceed its bandwidth allocation, it is slowed down.
UM maintains a variety of transport-level statistics which gives a real-time snapshot of UM's internal handling. For example, it gives counts for transport messages transferred, bytes transferred, retransmissions requested, unrecoverable loss, etc.
The UM monitoring API provides framework to allow the convenient gathering and transmission of UM statistics to a central monitoring point. See Monitoring UMS.
Copyright (c) 2004 - 2014 Informatica Corporation. All rights reserved.