The UMDS Server is a daemon that enables UMDS Clients to exchange messages with standard Ultra Messaging sending and receiving applications. The following image shows some of the UMDS Server components and functionality.

The UMDS Server consists of the following components:

UMDS Server - The UMDS Server is a daemon that contains a standard Ultra Messaging context, which sends and receives messages.
Workers - Workers exchange messages with UMDS Client applications over TCP connections. You can configure and run multiple worker instances to provide parallelism.
Web Monitor - Use the Web Monitor, a web-based user interface, to control operation of, and view the status of, the UMDS Server.
Configuration Options - When the umdsd UMDS Server starts, it reads configuration options from a UMDS Server Configuration File.

User Authentication <-

You can assign a user or application name, or both, and a password, to authenticate your client applications or individual desktop users. Authentication occurs when a user or application requests a server connection.

You assign user passwords in the UMDS user Element in the Basic Authentication File, which you specify in the UMDS Element "<authentication>" in the UMDS Server Configuration File. You can specify an application or user name in the UMDS user Element. If you specify <none> for the UMDS Element "<authentication>" in the UMDS Server Configuration File, the UMDS Server authenticates all applications and users.

Client Application Parameters <-

When a client application requests a server connection, the UMDS Server looks at a sequence of <client> element settings to determine what parameters to apply to the client application.

Operating parameters control the degree of resource utilization allowed by a client application, such as keep-alive intervals and thresholds. You can override all client application parameter values from multiple sources.

With overrides, you can select the optimal trade offs between flexibility and centralized control of client configuration. For example, a deployment that requires control would allow the client application to override fewer settings, which might simplify the job of the application programmer, but increase the responsibility of the server administrator.

UMDS Server factory defaults are the least restrictive, allowing clients to change any setting. However, you can configure a more restrictive, generic set of UMDS daemon UMDS Element "<client>" settings that disable client overrides for certain settings. You can also set up acceptable ranges of values for other settings. Plus, you can then configure other applications or users to use different settings, which maybe more or less restrictive than the generic set of parameters.

The following table shows the sequence of UMDS Element "<client>" settings the UMDS Server goes through when choosing the operating parameters for a particular UMDS Client application connection.

Step	Client Settings Used by UMDS Server	Can Configure Parameters	Can Authenticate User
1	Factory defaults. Requires no action by either application programmers or UMDS Server administrator.	Yes	No
2	UMDS Server configuration file UMDS Element "<client>" settings. Overrides factory defaults. You can apply different settings to different UMDS Servers across the enterprise.	Yes	No
3	Basic Authentication File `<application>`settings. Overrides UMDS Server Configuration File. These settings indicate one or more client applications that require different settings from the server settings in the UMDS Server Configuration File.	Yes	No
4	Basic Authentication File `<user>`settings. Override Basic Authentication File `<application>`. These settings indicate one or more users that require either authentication or different operating parameters or both.	Yes	Yes
5	Client application requests of certain settings. UMDS Server Configuration File and Basic Authentication File settings can deny the client application requests with the `client-write`attribute for any operation parameter.	Yes	No

The UMDS Server sends the resulting settings to the client application as the final phase of the initial connection handshake.

Note: For Steps 3 and 4, if you specify no Basic Authentication File and the client application does not provide a password, the UMDS Server permits the connection. However, the UMDS Server does not apply any <application>or <user>settings requested by the client application.

Keep Alive Timers During Idle Periods <-

UMDS provides keep alive timers so during periods of message inactivity, servers and clients can be aware of any unresponsiveness. Both the server and client have a keep alive interval and threshold. You configure these timers in the UMDS Element "<client>" of the umds configuration file.

The interval defines the time period in milliseconds between keep alive messages sent from either a client or server to the other (UMDS Element "<client-ka-interval>" and UMDS Element "<server-ka-interval>"). When a client or server sends a data message or keep alive message, it resets the interval.
The threshold defines the timeout for message traffic from the server or client to the other (keep alive or otherwise). A timeout results in disconnection. (UMDS Element "<client-ka-threshold>" and UMDS Element "<server-ka-threshold>"). When a client or server receives a data message or keep alive message, it resets the threshold.

The following figure shows the interaction of the interval and threshold configuration elements for a server when traffic from a client ceases.

When the server sends a message (data or keepalive) to the client, it resets the server-ka-interval. During the period when the server sends no data messages to the client, at the end of the server-ka-interval, it sends a keepalive message and resets the server-ka-interval. It continues to send keepalive messages at the expiration of the server-ka-interval as long as the connection exists.
When the server receives a message (data or keepalive) from the client, it resets the server-ka-threshold.
If the server receives no messages from the client, it disconnects the client when the server-ka-threshold timer expires.

During periods of inactivity, the interval used by one side prevents the threshold from being reached on the other side. Therefore, there is a relationship between client-ka-interval and server-ka-threshold and also between server-ka-interval and client-ka-threshold. The interval should be less than the related threshold.

Message Queues <-

The UMDS Server maintains a message queue for the messages that it forwards to each UMDS Client. This is called the "default" message queue. Because connections to UMDS Client applications use receiver-paced TCP, the UMDS Server queues these messages to prevent loss from fast senders.

In the UMDS Server Configuration File, you can configure the default queue's age limit and size limit with the "msg-age-limit" and "msg-q-size-limit" attributes of the UMDS Element "<server>". The UMDS Server deletes messages that stay in the queue longer than the age limit. If the queue reaches the configured size limit, the UMDS Server deletes the oldest messages in the queue to make room for new messages.

Note: When considering memory usage, be aware that when the UMDS Server creates sources and receivers, it also creates other buffers and caches. Examples include the topic Late Join message cache, and buffers created using the standard Ultra Messaging configuration options. Note also that when UMDS configuration files do not specify standard Ultra Messaging configuration options, these options use default values.

Per-Topic Message Queues <-

In addition to the default queue, the UMDS Server can be configured for one or more "per-topic queues". See the UMDS Element "<topic>".

Each per-topic queue has its own size limit, independent from the default queue. See UMDS Receiver Topic Options, option "topic-queue-size-limit". Note that per-topic queues do not have a message age limit.

When per-topic queues are not used, all messages flow through the default queue. When the default queue reaches its size limit and a new message arrives, the UMDS Server deletes the oldest message. This can be undesirable if the oldest message is for a different topic than the newest message. For example, suppose you have a price topic that has a high message rate, and a trade topic that has a much lower message rate. It is very important that every trade message be delivered, and less important for every price message to be delivered. If the price topic bursts at too high a rate and the default queue fills, it is undesirable for UMDS to drop trade messages.

By configuring a per-topic queue for the trade topic, trade messages will not be discarded when the default queue fills with price messages. Only old price messages will be discarded.

Note that when per-topic queues are enabled, message are still delivered to the client in the order that they arrived at the server. I.e. messages in the per-topic queues do not have a higher delivery priority, they must still wait until it is their turn to be sent to the client.

Also note that messages in the per-topic queues are still subject to being dropped. In the above example, if the price topic bursts to a higher rate than the UMDS client can consume, that topic's queue can grow to its limit, at which point messages can be dropped.

You can configure topics by pattern matching or explicit names (see "type" attribute of UMDS Element "<topic>").

Each queue maintains its own statistics, which you can view in the Web Monitor Client Details page.

Note that if a large number of topics are assigned their own queues, and each queue fills to its maximum size, this can result in undesirably large memory consumption. The UMDS Element "<server>" attribute "msg-q-size-limit" can be used to control memory growth.

Configuring Message Queue Size <-

Use the following information and examples to determine the optimum settings for the queue size configurations, and to properly size the physical memory contained in the UMDS Server host machine.

Approximating Per-Queue Memory Use <-

The msg-q-size-limit parameter sets the maximum number of message payload bytes that the UMDS Server allows in each client's "default" queue before deleting older messages to make room for new messages. The topic-queue-size-limit parameter does the same thing for per-topic queues. These limits do not include the Ultra Messaging overhead of approximately 900 bytes per message.

For example, if a message queue contains 2,000 25-byte messages, this total of 50,000 payload bytes does not exceed the msg-q-size-limit parameter default size of 1,048,576 bytes. However, with the overhead of 900 bytes, the queue actually uses 925 x 2,000 = 1,850,000 bytes.

Note that if per-topic queues are in use, the same calculations apply using the

Approximating the Number of Messages Per Queue <-

You can calculate the maximum number of messages that fit into a queue if you know the message payload size. For example, if all messages have a payload size of 25 bytes, then the default configuration of 1,048,576 bytes indicates that up to (1,048,576 / 25) = 41,943 messages can be enqueued.

When using individual topic queues, each UMDS Client has multiple queues. Thus, the total memory use is the sum of the memory use of all topic queues.

Calculating Optimal Queue Size Limits <-

If all connected clients are able to keep up with average message traffic, then the message queue consumes little or no memory. However, if a burst of high-rate traffic occurs, queues can fill up quickly as clients struggle to keep up. The following example demonstrates peak memory utilization.

If each message contains 25 bytes of user data, and the default queue size limit is set to 1,048,576 bytes, then the queue can grow to contain 41,943 messages.
If each 25-byte message consumes a total of 925 bytes including the UMDS overhead, a full queue consumes about 37 MB of memory.
If 80 client queues all fill to capacity, these queues collectively consume about 3 GB of memory.

Worker Configuration Guidelines <-

The default configuration of the UMDS Server assigns three workers to service all client connections. For each worker, four primary threads process data as follows:

One Client-to-Server Data Thread: handles all data produced by all sending Clients
One Server-to-Client Data Thread: handles all data dispatched to all receiving Clients
Two Ultra Messaging Backbone Context Processing Threads: shared by all workers
- UMS context worker thread processes all UMS streaming data from the Ultra Messaging Backbone, using UMS unicast and multicast transports.
- MIM context worker thread sends MIM data from sending Clients to the Ultra Messaging Backbone.

Four additional threads handle low volume internal command and control. These threads require a small fraction of the processing done by the primary threads.

Increasing Number of UMDS Workers <-

For each additional worker configured, the number of Client to Server Data Threads and Server to Client Data Threads increases by one. For example, four workers will result in four Client to Server Data Threads and four Server to Client Data Threads. Regardless of the number of workers configured, UMDS uses only two Informatica High Speed Message Backbone Processing Threads and 4 additional low volume command and control threads.

Workers CPU Cores and Performance <-

Due to the number of primary threads as described above, increasing the number of workers does not necessarily increase performance if the number of CPU Cores is four or less. For systems with greater than four cores, set the number of workers so the number of primary threads never exceeds the number of CPU Cores. See the table below.

Workers	Client to Server Threads	Server to Client Threads	Ultra Messaging Threads	Number of Primary Threads	Number of CPU Cores Recommended
1	1	1	2	4	4 or less
2	2	2	2	6	6
3	3	3	2	8	8
4	4	4	2	10	10

Proper performance analysis to determine the optimal configuration is recommended.

Workers Versus Client Load <-

Using multiple workers distributes work load among multiple threads. UMDS assigns each new client connection to a worker in round robin fashion. For the case of 1 worker, the single worker manages all client connections. If you configure two workers, then each worker services half the clients. Note, however, the following two limitations:

The server does not perform any load balancing of clients. For example, if two workers are servicing three clients each, but one of the six clients produces and/or consumes all the data, that client's worker will not distribute any processing chores to the other worker.
UMDS assigns new clients to workers in a round-robin fashion without regard to the current load. If, for example, a number of clients are evenly distributed across the workers and then all the clients assigned to a single worker disconnect, the UMDS Server does not move any clients to the idle worker. In addition, new connections continue to be assigned in a round-robin fashion.