Amazing what you can learn when you RTFM, ya know? From the Message Queueing in Windowx XP: New Features:
MSMQ 3.0 in Windows XP extends the regular MSMQ programming model from one-to-one to one-to-many. The traditional MSMQ model allows a single message to be sent to a single queue. However, the one-to-many messaging model enables clients to send the same message to multiple recipient queues. MSMQ 3.0 offers multiple ways to implement this model:
" Real-time messaging multicast
" Distribution lists and multiple-element format names
In MSMQ 3.0, one-to-many mechanisms provide the application developer with the fundamental tools required to build sophisticated publish and subscribe systems. These kinds of systems are useful for addressing reliable information dissemination scenarios.
Real-Time Messaging Multicast
MSMQ 3.0 provides a mechanism to send messages on top of IP multicast.
Specifically, MSMQ 3.0 uses the Pragmatic General Multicast (PGM) protocol (see http://www.ietf.org/internet-drafts/draft-speakman-pgm-spec-06.txt), which is becoming the de facto enterprise standard for obtaining a degree of reliability on top of IP multicast.
In MSMQ 3.0, when an application sends a real-time multicast message, a single copy of the message is sent on the network, but this message can then be received and processed by numerous destination applications. This method is extremely efficient if the same message has to be delivered to a huge number of receiving applications.
Real-time multicast messaging supports only an "at-most-once" quality of service. In particular, it does not support transactional sending. To send a real-time multicast message, the existing Send API has been extended so that the sender can specify a target IP multicast address. The receiver's programming model is not affected at all. An IP multicast address property can be attached to a queue, and subsequently every message sent to that multicast address will be inserted into the queue by MSMQ 3.0. Applications continue to read messages from the queue using standard MSMQ APIs and methods.
From a security point of view, standard MSMQ authorization and authentication continue to be available, but MSMQ 3.0 does not provide specific encryption or decryption for real-time multicast message.
Sounds like the Spammer's Full Employment Act to me!
And here is a performance issue I didn't know before:
Use Windows Security Sparingly
MSMQ uses the standard Windows security model. You can configure queues to permit only senders and receivers with appropriate security privileges. The tradeoff for including Windows security in messaging is that it takes about 2.5 times as long to send the same messages. By configuring MSMQ not to send the security descriptors associated with the sending application, you can obtain significant performance gains. To configure MSMQ not to send a security descriptor with the message, set the message property AttachSenderID to False (the default is True):