UDP Multicast in Silverlight 4

  • Article

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.