6 Appendix A: Product Behavior

Article
06/24/2021

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

The terms "earlier" and "later", when used with a product version, refer to either all preceding versions or all subsequent versions, respectively. The term "through" refers to the inclusive range of versions. Applicable Microsoft products are listed chronologically in this section.

Windows XP operating system
Windows Server 2003 operating system
Windows Vista operating system
Windows Server 2008 operating system
Windows 7 operating system
Windows Server 2008 R2 operating system
Windows 8 operating system
Windows Server 2012 operating system
Windows 8.1 operating system
Windows Server 2012 R2 operating system
Windows 10 operating system
Windows Server 2016 operating system
Windows Server operating system
Windows Server 2019 operating system
Windows Server 2022 operating system
Windows 11 operating system
Windows Server 2025 operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 2.1.1: Windows sends protocol messages to these ports unless the sending application specifies a different port in the HTTP format name.

<2> Section 2.1.2: PGM-based multicast SRMP messages are received directly into the MSMQ service, completely bypassing the web server. HTTP-based unicast SRMP messages are passed to MSMQ unprocessed by the web server. For both HTTP and PGM, SRMP messages contain HTTP 1.1 headers. In the case of PGM, the HTTP 1.1 header is ignored by MSMQ.

<3> Section 2.1.3: Exceptions that affect interoperability are noted for the following sections of [RFC3208]:

Section 2.1 (transmit window advance): Windows does not delay the window advancement based on NAK silence.
Section 5.1.1: Windows does not use any other definition of TXW_MAX_RTE.
Section 5.2: Windows does not do any negative acknowledgment (NAK) storm detection to protect against a denial of service attack. If a NAK request arrives for a sequence in the current window, a negative acknowledgment confirmation (NCF) packet is sent and followed by repair data (RDATA).
Section 5.3: Windows does not track propagation delays in computing the delay time of RDATA servicing. Prior to servicing an RDATA request, delay time is computed according to the formula in section 2.1.3.1 of this specification.
Section 6.1 (Non contiguous data): Windows delivers data to the receiver application only in the order sent, not in the order received.
Section 6.3 (transmitting a NAK): The multicasting of a NAK with TTL of 1 happens regardless of whether the PGM parent is directly connected.
Section 9.4 (OPT_JOIN): Windows does not send a late joining option.
Section 9.6: Windows does not use the synchronization (SYN) notification—either to notify the application about the start of the stream, or to notify a late joining receiver whether it missed any data or did not start from the beginning of the stream.
Section 9.6.1: Windows provides statistical information to applications about the data stream; for example, it provides rate and loss information. However, Windows does not provide any abstractions of the stream based on SYNs.
Section 9.7.1 (second paragraph): Windows does not provide any direct notification of the receipt of a finish (FIN) option. However, the session terminates gracefully when all data has been successfully delivered to the application.
Section 9.8.1: When the Windows receiver receives an OPT_RST, it terminates the session immediately without attempting to recover any pending data.
Section 9.8.2: A Windows source sends a session reset option (OPT_RST) only if the sends are canceled; otherwise, the session is closed gracefully. When the sends are canceled, the session is terminated immediately by the source, and subsequent NAKs are not processed.
Section 16.1 (second paragraph): Windows does not reset TXW_ADV_IVL_TMR if NAKs are received.
Section 16.4: Windows does not provide any other method of advancing the transmit window other than as specified in section 2.1.3.1 of this specification.

<4> Section 2.1.3.1: Windows allows a system administrator to configure alternate values of TXW_SECS and TXW_MAX_RTE.

<5> Section 2.2.4.1: If the value included in the <action> element is not prefixed by "MSMQ:", Windows completely ignores the contents of the element.

<6> Section 2.2.4.1: If the value included in the <action> element is not prefixed by "MSMQ:", when Windows sends delivery and commitment receipts, it treats the contents of the <action> element as though it contained only the string "MSMQ:".

<7> Section 2.2.4.3: Windows follows this rule but uses <SourceQMGuid> if the GUIDs do not match.

<8> Section 2.2.4.4: This specification imposes a stricter standard than the one specified in [MSDN-WSROUTING].

<9> Section 2.2.4.4: In the case of an empty <via> element, Windows allows the form "<via/>" but does not allow the form "<via></via>".

<10> Section 2.2.4.5: Windows does not generate these elements in any protocol messages and ignores them, if present.

<11> Section 2.2.5.1.3: Windows does not generate this element in any protocol messages and ignores it, if present.

<12> Section 2.2.6: Windows always generates this element in any protocol message. If the element is omitted, Windows processes the message and assumes default values for all subelements.

<13> Section 2.3: For Windows NT operating system and Windows 2000 operating system, this protocol uses the Message Queuing (MSMQ): Directory Service Protocol [MS-MQDS].

<14> Section 2.3: For the Message Queuing (MSMQ): Directory Service Protocol [MS-MQDS], the Directory Service schema elements are described in [MS-MQDS] sections 2.2.10 and 3.1.4.21.1 through 3.1.4.21.4.

<15> Section 3.1.1.1.3: Each Windows client and server generates a unique GUID upon setup and stores it durably as a binary value under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\MachineCache\QMId registry key.

<16> Section 3.1.1.1.5: A Windows implementation persistently stores up to the last 10,000 Message.Identifier values. Any values that are older than 30 minutes are discarded.

<17> Section 3.1.1.1.5: The Windows default time-out is 30 seconds. The time-out grows as the number of sequential time-outs occur. The first, second, and third time-outs have periods of 30 seconds. The fourth, fifth, and sixth time-outs are 5 minutes. The seventh, eighth, and ninth time-outs are 30 minutes, and thereafter, the time-out period is 6 hours.

The Microsoft implementation provides a registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Msmq\Parameters\SeqResend13Time that can be used by the client to specify resend times, in seconds, that are different from the default values for the first, second, and third time-outs.

The Microsoft implementation provides a registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Msmq\Parameters\SeqResend46Time that can be used by the client to specify resend times, in seconds, that are different from the default values for the fourth, fifth, and sixth time-outs.

The Microsoft implementation provides a registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Msmq\Parameters\SeqResend10Time that can be used by the client to specify a resend time, in seconds, that is different from the default value for the tenth time-out.

<18> Section 3.1.2.2: The Windows default time-out is 30 seconds. The time-out grows as the number of sequential time-outs occurs. The first, second, and third time-outs have periods of 30 seconds. The fourth, fifth, and sixth time-outs are 5 minutes. The seventh, eighth, and ninth time-outs are 30 minutes; thereafter, the time-out period is 6 hours.

<19> Section 3.1.2.4: The Windows default value for the Session Cleanup Timer is 300,000 milliseconds. This default value can be overridden by setting the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\CleanupInterval to the desired value, in milliseconds.

<20> Section 3.1.3.1: The Windows default time-out is 30 seconds. The time-out grows as the number of sequential time-outs occur. The first, second, and third time-outs have periods of 30 seconds. The fourth, fifth, and sixth time-outs are 5 minutes. The seventh, eighth, and ninth time-outs are 30 minutes; thereafter, the time-out period is 6 hours.

<21> Section 3.1.3.1: The Microsoft implementation provides a registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Msmq\Parameters\SeqResend13Time that can be used by the client to specify resend times, in seconds, that are different from the default values for the first, second, and third time-outs.

<22> Section 3.1.3.1: The Microsoft implementation provides a registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Msmq\Parameters\SeqResend46Time that can be used by the client to specify resend times, in seconds, that are different from the default values for the fourth, fifth, and sixth time-outs.

<23> Section 3.1.3.1: The Microsoft implementation provides a registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Msmq\Parameters\SeqResend46Time that can be used by the client to specify resend times, in seconds, that are different from the default values for the seventh, eighth, and ninth time-outs.

<24> Section 3.1.3.1: The Microsoft implementation provides a registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Msmq\Parameters\SeqResend10Time that can be used by the client to specify a resend time, in seconds, that is different from the default value for the tenth time-out.

<25> Section 3.1.3.1: The default setting is 20,000 milliseconds on a local area network (LAN). The Microsoft implementation provides a registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Msmq\Parameters\RoundTripDelay that the client can use to specify additional time, in seconds, that is different from the default value.

<26> Section 3.1.5.2.1.1: The Windows dead-letter queue, transactional dead-letter queue, and queue journal are named "Deadletter$", "XactDeadletter", and "Journal$", respectively.

<27> Section 3.1.5.2.1.2: The Windows dead-letter queue, transactional dead-letter queue, and queue journal are named "Deadletter$", "XactDeadletter", and "Journal$", respectively.

<28> Section 3.1.5.2.2: The Windows dead-letter queue, transactional dead-letter queue, and queue journal are named "Deadletter$", "XactDeadletter", and "Journal$", respectively.

<29> Section 3.1.7.2.4: The generation of MD5 hashes is supported only on Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 operating systems.

<30> Section 3.1.7.9: Windows XP and Windows Server 2003 do not perform the exception check. A match in the OutboundRedirectionCollection (section 3.1.1.1.10.1) ADM element always results in the value of DestinationHost being set.

<31> Section 5.1: Microsoft Message Queuing on Windows XP and Windows Server 2003 uses SSL 3.0 security protocol. On Windows Vista and later client releases, and Windows Server 2008 and later server releases, the security protocol is determined by the underlying Secure Channel (SChannel) security package specified in [RFC2246].

6 Appendix A: Product Behavior

Additional resources