Network Sessions

Applies To: Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server Technical Preview, Windows Vista

Messages are sent to remote computers in network sessions. When a message is sent to an opened queue on a remote computer, Message Queuing stores the message in an outgoing queue on the local computer. Message Queuing attempts to establish a network session with the target computer or with the server for routing the message in the next hop on its way to the target computer if a network session does not already exist.

MSMQ 3.0 establishes the following three types of network sessions, depending on the transport protocol used to send the message:

• Native-protocol sessions

  Message Queuing establishes sessions with target computers using the native MSMQ protocol over TCP transport for sending messages to private, public, machine, and direct format names other than HTTP direct format names, as well as to the elements of distribution lists and multiple-element format names that are not specified by HTTP format names. Messages sent in these sessions consist of binary packets. Note that only native-protocol sessions are established in the previous versions of Message Queuing.

• HTTP/HTTPS sessions

  Message Queuing establishes HTTP/HTTPS sessions over TCP transport with target computers for sending messages to URL-named queues specified in direct format names containing HTTP or HTTPS as the protocol (HTTP format names). Messages sent in these sessions consist of SRMP packets.

• Multicast sessions

  Message Queuing establishes a session over TCP transport with each computer hosting a queue that is listening to the multicast address and port specified in a multicast address format name used to send a multicast message. Messages sent in these sessions consist of SRMP packets.

Establishing Network Sessions

Message Queuing repeatedly attempts to connect to the applicable computer until the time-to-reach-queue timer of the message expires. In MSMQ 3.0, by default, the first 10 attempts are made with increasing delays ranging from 4 seconds to 64 seconds. These are followed by additional attempts every 64 seconds until the time-to-reach-queuetimer expires. You can change the default lengths of the time intervals between connection attempts by adding and setting the following registry entry on the local computer.

HKLM\SOFTWARE\Microsoft\MSMQ\Parameters\WaitTime  

When you specify a new value for this registry entry, set it to the number of milliseconds that Message Queuing should wait before trying again to connect to the applicable computer. When this registry entry is added and set, all the delays between connection attempts are equal to the wait time specified.

Session Concentration

After network sessions are established, Message Queuing tries to concentrate sessions and reuse existing sessions to send and receive messages.

Native-protocol sessions can be reused for bidirectional message transport. Additional messages can be sent from the source computer to any queue on the target computer, and messages, including acknowledgment messages and response messageR, can be sent back from the target computer to any queue on the source computer without opening a new session.

For this reason, after a network session is established, Message Queuing internally caches information about any queues that become active in the session and holds the session open for a specified time interval while the session is not in use. If a network session remains inactive for more than the specified time interval, Message Queuing erases the internally cached information about the corresponding queues and ends the session.

The default time interval for maintaining the internally cached queue information and keeping an inactive native-protocol session over TCP open is 5 minutes (300,000 milliseconds) on a client computer or 2 minutes (120,000 milliseconds) on a Message Queuing server. You can change the default value of this time interval by adding and setting the following registry entry on the local computer.

HKLM\SOFTWARE\Microsoft\MSMQ\Parameters\CleanupInterval  

When you specify a new value for this registry entry, set it to the number of milliseconds that Message Queuing should wait before erasing the internally cached information about the active queues and closing an inactive native-protocol session.

Unlike native-protocol sessions, HTTP/HTTPS sessions can be reused for message transport in only one direction to a single destination queue. Additional HTTP messages can be sent only from the source computer to the same destination queue on the target computer without opening a new session.

The default time interval for maintaining the internally cached queue information and keeping an inactive HTTP/HTTPS session open is 2 minutes (120,000 milliseconds) on all computers. You can change the default value of this time interval by adding and setting the following registry entry on the local computer.

HKLM\SOFTWARE\Microsoft\MSMQ\Parameters\HttpCleanupInterval  

When you specify a new value for this registry entry, set it to the number of milliseconds that Message Queuing should wait before erasing the internally cached information about the destination queue and closing an inactive HTTP/HTTPS session.

Like HTTP/HTTPS sessions, each multicast session can be reused for message transport in only one direction to a single queue. Additional multicast messages can be sent only from the source computer to the same destination queue on the target computer without opening a new session.

The default time interval for maintaining the internally cached queue information and keeping an inactive multicast session open is 5 minutes (300,000 milliseconds) on all computers. You can change the default value of this time interval by adding and setting the following registry entry on the local computer.

HKLM\SOFTWARE\Microsoft\MSMQ\Parameters\MulticastCleanupInterval  

When you specify a new value for this registry entry, set it to the number of milliseconds that Message Queuing should wait before erasing the internally cached information about the active queues and closing an inactive multicast session.

More Information