UDP Multicast in Silverlight 4
In Silverlight 4, we have added multicast support. If you’re not familiar with multicast, here’s a quick scenario to explain what it is and why it might be useful to you.
Scenario Overview
Suppose your company provides market data and you need to distribute the same commodity and value records to 50,000 client workstations. It would be quite a load on the server and network infrastructure to do this in the traditional client/server TCP model where all 50,000 clients connect to the server to receive the data feed in round-robin fashion.
Wouldn’t it be great if the server could just send the data once and let the network infrastructure pass it on to all subscribers in an efficient manner? That would take the load off the server since it would only be sending out the data once instead of 50,000 times. Conveniently, that’s precisely how multicast works, and this makes it a useful technique for video and content distribution.
User Datagram Protocol (UDP)
User Datagram Protocol (UDP) supports multicast and is the most common low-level protocol for IP multicast. Because it’s so low-level, there are some key things you should be aware of:
- UDP by nature is not “reliable” like TCP. This means messages are not guaranteed to be received in order or at all. There are, however, forms of reliable multicast, such as Pragmatic General Multicast (PGM) which can be implemented on top of UDP.
- UDP has no built in IP address spoofing protection. Just because a message indicates it came from a particular IP address, you can’t be sure it did, so your application protocol needs to implement this protection if you need to be sure of the origin of your messages.
Multicast Concepts
Multicast Groups and Addresses
People are most familiar with unicast addresses, which are used to direct packets to a single host. Alternatively, a special multicast address can be used to deliver a packet to a group of destinations; specifically, all nodes which have explicitly joined the multicast group as identified by the multicast address. The 224.0.0.0/4 IPv4 and ff00::/8 IPv6 address ranges have been reserved for identifying multicast groups.
Joining a Multicast Group
When a computer or device wants to join a multicast group, it performs a special exchange with its router using the Internet Group Management Protocol (IGMP) or the Multicast Listener Discovery (MLD) protocol. This lets the router know the computer is interested in receiving traffic from the multicast group. To leverage multicast, it must be supported by the router and not otherwise blocked.
Multicast is often deployed within corporate networks for efficient transmission of video. Be aware that it is common for corporate firewalls to block multicast traffic at the edge so that it cannot traverse the boundary of the corporate network. Many home ISPs enforce similar restrictions.
It’s also worth mentioning that there are multiple versions of IGMP and MLD, but the specifics of negotiation are up to the client OS stack and the first-hop router; it’s not something your application needs to worry about.
Finally, in addition to joining a multicast group, a complementary operation to leave the group is also available.
Multicast Sources
The node or nodes sending data to the group are known as multicast sources. There are two common forms of IP multicast differentiated by the number of sources in the group:
- Single Source Multicast / Source Specific Multicast (SSM) – A single, well-known source identified by a unicast IP address will send to the group (one-to-many).
- Any Source Multicast (ASM) – Any member of the group may behave as a multicast source and transmit data to the group (many-to-many).
In the case of any source multicast, additional operations are provided to block and unblock specific sources so that messages can be filtered by source address. One of the benefits of SSM is that with a single source known ahead of time, the multicast tree can be built more efficiently when nodes join the group.
New APIs
In correlation to the multicast forms above, two new classes have been introduced to the System.Net.Sockets namespace, UdpSingleSourceMulticastClient and UdpAnySourceMulticastClient. If you’re familiar with Sockets or UdpClient in the .NET Framework, the available operations should look very familiar to you. Here are some brief, simplified samples to demonstrate the basics.
Construction
// Construct a client for the multicast group 224.0.0.1 port 3000
// Note that only ports >= 1024 are supported for Silverlight
var client = new UdpAnySourceMulticastClient(IPAddress.Parse(“224.0.0.1”), 3000);
Join Group
// Join the multicast group
client.BeginJoinGroup((result) => EndJoinGroup(result), null);
Message Receive
// Receive a message
client.BeginReceiveFromGroup(buffer, offset, count,
(result) => { messageLength = EndReceiveFromGroup(result, sourceAddress); }, null);
Leave Group and Dispose
// Leave the group and cleanup connections
client.Dispose();
In a real application, the async calls would be chained together. For a more detailed example showing this, see SilverChat on MSDN Code Gallery.
Browser Security
Because multicast in corporate environments is often blocked at the edge, Silverlight should not be able to circumvent that trust model by allowing code from an untrusted domain to run unchecked within the corporate network where it could potentially receive and forward privileged data. To prevent this, Silverlight requires that a Silverlight Multicast Policy Responder join the multicast group to authorize Silverlight clients. If multicast has been blocked at the corporate edge, then only a service behind the corporate firewall will be able to authorize Silverlight clients, thus maintaining the original network boundary.
You are free to deploy the responder in any way you choose, whether on the same or separate machine as your multicast source.
For details of the policy protocol used and to review a sample implementation, please see the Silverlight Multicast Policy Responder sample also on MSDN Code Gallery.
Conclusion
This article covered how multicast can be used to reduce server and network infrastructure load, the new APIs added in Silverlight 4 to support these features, the special requirements to maintain browser security, and finally, some important points to consider for your application protocols built on UDP. Please let us know if you have questions about these new features. In addition to blog comments, you may also direct inquiries to the forum.
Comments
Anonymous
December 11, 2009
Thanks. this feature is great and clear . I have a question about the possible sources and types of data that we might use to publish in a multicast fashion : 1- is it possible to stream binary data in this mode? 2- what are the possible sources of these data? thanks again,Anonymous
December 15, 2009
Indeed, you can stream binary data, though keep in mind that UDP doesn't make ordering or reliability guarantees, so your streaming protocol will need to handle dropped or out of order packets. Data can come from any multicast source. This might be an intranet media or conferencing server, or even devices on a home network.Anonymous
January 16, 2010
Thanks for wonderful Article, After a some googling I am still wondering if I want to have a Multicast source do I need to register for an Multicast IP address (D class IP) with AINA or any simple Unicast IP would be sufficient? It would be Greate if you Give us some Idea about multicast Application live deployment.Anonymous
January 18, 2010
Is it possible to use DRM v10 like in windows media player based multicast stream with a silverlight modified player that we have and that already works with DRM v10 in a unicast stream ? If not is it possible to use latest playready drm and also wich encoder could be used then ?Anonymous
January 19, 2010
The multicast group address MUST be from the reserved range (224.0.0.0/4 or ff00::/8), so that routers know you want the traffic to be delivered via multicast and not unicast. If you expect your application to be deployed on many networks, it's polite to get a reserved address from the IANA so that you won't accidentally send traffic to other applications that use the same address. If you only expect your application to be used on networks you control, it's sufficient to pick an address that isn't already allocated to someone else. Hope this helps!Anonymous
January 19, 2010
Leon, the MediaElement control in Silverlight doesn't support multicast DRM natively right now, but it would be possible to use the multicast support described here as a transport to feed a MediaStreamSource (using the standard codecs and DRM already supported by Silverlight) which MediaElement could consume.Anonymous
January 29, 2010
The comment has been removedAnonymous
February 03, 2010
Starting with SL4, MediaElement can take a .NSC file as input for multicast. Can you tell us more about how you're hooking this up and whether it is protected content via DRM (not currently supported by MediaElement, see above comment)? What does your network configuration look like? Where is the client computer in relation to the multicast source? To help troubleshoot, we need more info. Thanks.Anonymous
April 16, 2010
If will be cool if we can have an option to use UDP over the internet right after connecting to a TCP which use connection policy, with this we can have an option to send unreliable message to UDP without choking the TCP and reliable message will be send only via TCP with this features I'm sure Silverlight will surpass other browser plug-in.Anonymous
April 20, 2010
Hi i am trying to stream live video from mulitcast IP e.g : udp://224.168.116.253 : 4765 is it possible with silverlight 4, i tried it with silverlight 3.0 it doesn't work, if i just set the above url as a source for silverlight player should it work. Please help me with this. Thanks in advanceAnonymous
April 20, 2010
Will this work with pure ip multicast using something like mpeg-ts and h264 or is the current implementation tied to WMS?Anonymous
May 03, 2010
Raj, I am trying to do the same thing than you, did find a solution ? Thanks