INFO: CAL and Connection Usage by MSMQ (183666)

SUMMARY

This article describes how Microsoft Message Queue Server (MSMQ) uses Microsoft Windows NT and Microsoft SQL Server Client Access Licenses (CALs). The purpose is to bring together and clarify information from different sources on this topic.

MSMQ checks Windows NT CALs only for message transfer sessions. A CAL is not required for other forms of MSMQ network traffic, such as creating, locating, and deleting queues. In addition, MSMQ servers use at least one SQL CAL for local access to the Message Queue Server Information Store (MQIS) database.

In the cases where messages are being transferred, the remote MSMQ Queue Manager (QM) looks for an available CAL, and also checks against hard-coded internal limits before permitting the MSMQ message transfer session to be established. If either the internal limit has been reached or a Windows NT CAL is not available, the QM will refuse to establish the session. The resulting behavior depends on the operation being attempted and the properties of the message being sent.

MSMQ connectivity limits are determined by the operating system on which MSMQ runs. Windows NT Server version 4.0 has a 25 CAL limit, or fewer if the server has fewer CALs available. With Windows NT Server version 4.0 Enterprise Edition, only the available NT CALs limit the number of MSMQ connections.

MORE INFORMATION

MSMQ enforces these two general rules for counting CALs:

All message transfer sessions are counted.
All operations performed by a single computer are counted together and consume only one CAL by the remote QM.

Some specific situations are handled as exceptions and are detailed at the end of this article.

Message Transfer Sessions

A message transfer session occurs when a QM connects to a remote QM for the purpose of exchanging messages. Note that the Dependent Client (DC) does not have a QM, which causes a special case.

There are three cases which generate a message transfer session between two computers: sending messages, receiving messages (remote read), and DC operation. Each has a slightly different behavior.

Sending Messages

Sending messages is an asynchronous operation. Opening a remote queue for send does not immediately consume a CAL, because a QM session is not established immediately for transfer of the message. The CAL will be used when the sending QM eventually establishes a session with the remote QM and transfers the message. From the application perspective, the Send method or MQSendMessage call should never fail for lack of a CAL.

Example:
When a message is being sent to a remote computer for which a CAL limit has been reached, the queue locate and open method will succeed, because CALs are not counted for these operations. From the application perspective, the send method will succeed when the local QM takes ownership of delivering the message. The QM, however, must establish a session with the remote QM to transfer the message. It will not be able to deliver the message, but will retry until a CAL becomes available on the remote computer permitting a session to be established, or the message itself expires.

Receiving Messages

Unlike sending, remote read is a synchronous operation. Opening a remote queue for receive immediately consumes a CAL on the remote computer.

Example: When an attempt to open a remote queue for receive on a computer for which a CAL limit has been reached, the open method itself will fail immediately.

Dependent Client

The Dependent Client behavior is detailed as a special case below.

Example: If a QM on a computer is sending messages to one queue on a computer and is receiving messages from another queue on the same computer, the remote QM counts only one CAL.

Specific Situations and Exceptions

MSMQ Server

There is no CAL-enforced limit on number of sessions between MSMQ Servers.

For MSMQ client accesses to the Server, CALs are counted as above.

MSMQ Independent Client (IDC)

An IDC has a limit of ten concurrent sessions (MSMQ and remote-read combined) with other IDCs. The IDCs do not count the outbound sessions with MSMQ Servers. The MSMQ Servers will count the IDC connection as noted above.

There is an additional caveat for Windows NT Workstation IDCs: Windows NT Workstation imposes a total limit of ten inbound connections to the computer. Therefore if other computers have non-MSMQ inbound connections to the workstation computer, the workstation limit will be reached before the MSMQ limit. Windows 95 does not impose this connection limit.

Note that the Administrator program Help file states that MSMQ clients (both independent and dependent) are limited to a maximum of ten concurrent sessions with other MSMQ clients. This is incorrect; the limit is for IDCs only, not DCs.

MSMQ Dependent Client (DC)

The DC has no local resources or QM, and therefore has no need for an inbound connection or the counting of CALs. For outbound connections, however, the DC must have a connection to its host server, and the server makes the connection and counts the CAL on the DC's behalf.

The host server does not count the DC connection until the DC opens a queue on the server. For each remote queue outbound connection that the server makes to another QM, a CAL is counted.

Standard Windows NT Server computers with the Option Pack installed are limited to 25 DCs. If the Windows NT Server computer (with the Option pack installed) has fewer than 25 CALs, that is the limit. That is, it can not be more than 25 but it can be fewer.

Windows NT Server 4.0 Enterprise Edition is limited only by server CALs.

Microsoft SQL Server

By default, MSMQ Server computers use one SQL Server CAL for the SQL session it uses to access the local MQIS database. To tune performance, the number of sessions can be increased to a maximum of 15, by double-clicking the MSMQ icon in Control Panel. Each additional session added will consume one additional CAL.

MSMQ Client computers do not connect directly to SQL Server on the MSMQ Server, and therefore do not use SQL Server CALs. MSMQ Client computers access the server's MQIS through MSMQ APIs which do not use SQL CALs (as noted above).