MSMQ 3.0 and Multicast
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):
mq.DefaultPropertiesToSend.AttachSenderId=false;
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):
mq.DefaultPropertiesToSend.AttachSenderId=false;
Yep, the only problem with this, is that PGM is not actually implemented in Winsock on XP. Its is however in 2003 server.
ReplyDeleteEven the .NET docs say its imeplemented (XP) until you actually try and use it, you get and unsupported transport exception.
I find this really crap. PGM is a really useful protocol, based on the origional Tibco Rendezvous transport layer, which they revised and submitted as an open standard. MS though is banging on about web services with its new messageing service, and it does not seem to include probably the fastest and most scalable protocol going for reliable messaging. Its why its used so much in finance on GBit lans for diseminating vast amounts of realtime market data.
Hi,
ReplyDeletewe have this test program which is sending 100000 multicast messages. we were comparing performance of multicast send with send to individual queue. It was observed that messages sent via multicast option takes longer time to send messages to the queue than sending messages to individual queue. eg:
100000 messages sent to individual queue(3 queues simultaneously) took around 2 sec whereas multicast to 3 queues was still going on. we have tried this test on both XP and 2003 server.
Please let me know if this multicast performancecould be improved anyhow...
Hi,
ReplyDeletedoes this msmq multicast works on internet or only on local network?
rgds