Friday, July 10, 2009

In the previous post we’ve reviewed the multicast addressing technology and examined some of its pitfalls.

In this post we’ll dive through the implementation of a simple application that allows sending and receiving multicast data over the LAN, while enabling the selection of the network interfaces (IPEndPoint) through which the multicast traffic will be sent and received.

As illustrated in the previous post, setting the network interface is crucial when the host is connected to two or more networks or have two or more network cards installed and enabled.

Configuration

The MulticastConfiguration class encapsulates the configuration entered by the user. It exposes two factory methods that allow instantiating the class for single network hosts and for multi network hosts. The 1st factory method requires only the multicast address/port of the sender and the receiver, while the 2nd factory method also requires the unicast address of the network card of the sender and the receiver.

Code Snippet

classMulticastConfiguration

{

readonlyIPAddress m_SendMulticastAddress;

readonlyint m_SendPort;

readonlyint m_ReceivePort;

readonlyIPAddress m_ReceiveMulticastAddress;

// Multihomed Support

readonlyIPAddress m_SendNetworkCardAddress = IPAddress.Any;

readonlyint m_SendNetworkCardPort;

readonlyIPAddress m_ReceiveNetworkCardAddress = IPAddress.Any;

public MulticastConfiguration(

IPAddress sendMulticastAddress,

int sendPort,

IPAddress receiveMulticastAddress,

int receivePort)

{

m_SendMulticastAddress = sendMulticastAddress;

m_SendPort = sendPort;

m_ReceiveMulticastAddress = receiveMulticastAddress;

m_ReceivePort = receivePort;

}

public MulticastConfiguration(

IPAddress sendMulticastAddress,

int sendPort,

IPAddress receiveMulticastAddress,

int receivePort,

IPAddress sendExplicitSourceAddressm,

int sendExplicitSourcePort,

IPAddress receiveExplicitSourceAddress)

: this(

sendMulticastAddress,

sendPort,

receiveMulticastAddress,

receivePort)

{

m_SendNetworkCardAddress = sendExplicitSourceAddressm;

m_SendNetworkCardPort = sendExplicitSourcePort;

m_ReceiveNetworkCardAddress = receiveExplicitSourceAddress;

}

publicstaticMulticastConfiguration CreateForSingleInterfaceNetwork(

IPAddress sendMulticastAddress,

int sendPort,

IPAddress receiveMulticastAddress,

int receivePort)

{

returnnewMulticastConfiguration(

sendMulticastAddress,

sendPort,

receiveMulticastAddress,

receivePort);

}

publicstaticMulticastConfiguration CreateForMultiHomedNetwork(

IPAddress sendMulticastAddress,

int sendPort,

IPAddress receiveMulticastAddress,

int receivePort,

IPAddress sendExplicitSourceAddressm,

int sendExplicitSourcePort,

IPAddress receiveExplicitSourceAddress)

{

returnnewMulticastConfiguration(

sendMulticastAddress,

sendPort,

receiveMulticastAddress,

receivePort,

sendExplicitSourceAddressm,

sendExplicitSourcePort,

receiveExplicitSourceAddress);

}

publicIPAddress SendMulticastAddress

{

get { return m_SendMulticastAddress; }

}

publicint SendPort

{

get { return m_SendPort; }

}

publicIPAddress ReceiveMulticastAddress

{

get { return m_ReceiveMulticastAddress; }

}

publicint ReceivePort

{

get { return m_ReceivePort; }

}

publicIPAddress SendNetworkCardAddress

{

get { return m_SendNetworkCardAddress; }

}

publicint SendNetworkCardPort

{

get { return m_SendNetworkCardPort; }

}

publicIPAddress ReceiveNetworkCardAddress

{

get { return m_ReceiveNetworkCardAddress; }

}

}

Transport

The TransportAgent class is in charge of creating the sockets that receive and send the data, joining to the multicast group (i.e. sending IGMP package to the router) and binding both sockets to the appropriate network interface.

Host

All the host has to do is to read the configuration from the UI, instantiate the configuration class, and instantiate the transport class - injecting it with the configuration instance and with delegate to OnMessageReceived callback that will be called when ever data arrive.

Receiving Multicast Data

Debugging

My choice for network protocol analyzer is Wireshark which is the best analyzer available today, it’s released under the GNU General Public License (GPL) so it can be used freely.

To get started, download the source code and run the multicast tester application, download Wireshark, run it and start a capture session,

IGMP

In order to get a feeling about the way that multicast addressing works – let’s review the IGMP message that is sent to the router when the receiver socket joins to the multicast group (see TransportAgent line 166).

Enter ‘igmp’ in Wireshark filter.

In the multicast tester application, press ‘Connect’. The ‘network card interface’ in the receiver configuration is set to my local machine upper network card address.

As a result, IGMP package was sent to the network, requesting it to add network interface with address 192.168.2.100 (which is my upper network card address) to the multicast group 224.0.0.12. Consequently, the network will deliver any multicast data sent to group 224.0.0.12 to address 192.168.2.100.

Now, In the multicast tester application, press ‘disconnect’.

As a result, IGMP package was sent to the network, requesting it to remove the network interface from the group.

Sending Multicast Data – Single Network

Enter ‘udp’ in Wireshark filter.

In the multicast tester application, leave the ‘Network Card Address’ and ‘Network Card Port’ in the sender configuration blank, press ‘Connect’, enter some string to the message text box and press ‘Send’

As a result, the string that was specified (in this case ‘aviad’) is sent form the network card 192.168.2.100, port 3704. Since we didn’t specify the network card address and port – the operation system took the liberty to select network card and port.

Sending Multicast Data – Multihomed Network

In the multicast tester application, set the sender ‘Network Card Address’ to one of your network cards address and set the ‘Network Card Port’ to 1234, press ‘Connect’, enter some string to the message text box and press ‘Send’.

As a result, the string is sent form the network card 192.168.2.100, port 1234. Since we did specify the network card address and port – the network card and the port from which the string was sent were NOT the selection of the operation system. Even though in the previous case the operation system selected the same network card that we specified, in cases where there are more than 1 enabled and active network cards in the machine - you must specify the appropriate network address or your multicast may be delivered though the wrong network.

Tuesday, July 7, 2009

The IP multicast model has been described as follows: “You put packets in at one end, and the network conspires to deliver them to anyone who asks”. That sounds pretty simple indeed, but as you spend more time with applications that deliver multicast services you find that in many cases you will ‘put packets in at one end, look at the network protocol analyzer, and see nothing that you expect’. The truth of the matter is that getting multicast applications to work as expected requires deep understanding of the network topology and the underlying routing devices.

This post reviews the multicast addressing technology along with in detail illustrations of some of the pitfalls that are often encountered when deploying multicast applications.

In my next post you can find walkthrough of C# sample application that allows sending and receiving multicast data over the network.

How does it Work?

In multicast applications, the sender defines IP multicast group address (from 224.0.0.0 to 239.255.255.255) to which is send data packets. Receivers inform the network that they are interested in receiving data packets sent to a certain group by sending Internet Group Management Protocol (IGMP) package to the closest network node (router, IGMP querier). The node is in charge of maintaining multicast distribution trees such that data packets sent to a multicast group reach all receivers which have joined the group.

Why Use Multicast?

The great thing about multicast addressing is that in order to distribute a message to multiple receivers - the sender have to dispatch only one message over the wire, while it’s the network (e.g. intermediary routers) responsibility to copy and distribute the message to all the receivers in the group. In case there aren’t any receivers that had joined the group – the network drops the message. The fact that the sender is unaware of the receivers greatly improves the application ability to scale to a large receiver population

The Pitfalls

Developing application that sends and receives multicast streams over the network is considered a fairly simple task. You can get pretty fast to the point where everything seems to work fine in the integration labs, were all the PCs communicate through a single network card and connected through few well known switches. The problems start when the application first meet the client network that is often spitted by VLANs and filled with all kinds of Cisco goodness. Unavoidably, you’ll find yourself steering at the network sniffer trying to figure out why you don’t see packages from group X even though the IGMP package was sent to the router, or why you do see packages from group Y - even though your application had never requested to join this particular group (No IGMP package was sent).

Where is my Multicast?

Multihomed Network

In case a host is connected to two or more networks or have two or more network cards installed and enabled – senders must explicitly state to which network interface (represented by the unicast IP address of the network card) they want to send the multicast traffic, and receivers must explicitly state from which network interface they want to receive multicast traffic. If they don’t – the operation system takes the liberty to choose the network interface, and the multicast traffic has 50% chance of reaching to the intended destination.

A common mistake that developers make is not binding the socket used for sending multicast traffic to the appropriate network card endpoint, or binding the socket used for receiving multicast to the address Any (0.0.0.0).

This mistake is so common because developers often assume that UDP unicast socket and UDP multicast sockets that are being used to send data can be implemented alike, and that sockets that are being used to receive multicast data can bind to IPAddress.Any (0.0.0.0). This is true when the host has single network card, but not true for host that lives in multihomed network.

Firewall

In case the machine firewall is turned on, and the firewall is NOT configured to relay transports from a certain multicast group (and corresponding UDP port) – your application will not receive messages from that group.

Inter VLAN

In case the sender and the receivers don’t sit on the same VLAN, the receivers will not receive messages from the sender.

Switch doesn’t Support IGMP Snooping

In case the sender is connected to a switch that support IGMP snooping (which means that it relay multicast messages only through ports which sent IGMP message), and the receiver is connected to another switch that doesn’t support IGMP snooping - the multicast relaying mechanism will "breaks down" in the absence of an mrouter port, thus the receiver will not receive the messages from the sender.

If you want a fix for this solution, you must have the switches somehow learn or know of an mrouter port. When the switches know their mrouter port, the right Switch (that doesn’t support IGMP snooping) relays out the IGMP report that it receives through its mrouter port. From the perspective of the left Switch, it received merely another IGMP report. The left switch adds that port into its IGMP snooping table and begins sending out multicast traffic on that port as well. At this point, the right Switch receive the multicast traffic, and the application works as expected.

Why am I getting this Multicast?

Broadcasting Multicast Traffic

Switches that cannot understand multicast addresses usually broadcast multicast traffic to all the members of a LAN. Machines that are connected to such switches will see multicast traffic from groups that they’ve never registered to.

Port Mirroring

In case the machine is connected to a router port that is configured as ‘port mirroring’ – the machine will receive multicast streams form all the groups.

Port mirroring, also known as a roving analysis port, is a method of monitoring network traffic that forwards a copy of each incoming and outgoing packet from one port of a network switch to another port where the packet can be studied. A network administrator uses port mirroring as a diagnostic tool or debugging feature, especially when fending off an attack. It enables the administrator to keep close track of switch performance and alter it if necessary. Port mirroring can be managed locally or remotely.

Multicasting over WAN

Source-specific multicast (SSM) make multicasting packages over the WAN eligible by reducing the amount of multicast routing information that the network must maintain. With SSM receivers supply the sender’s source address to the routers as a part of joining the group (by setting the receiver socket option MCAST_JOIN_SOURCE_GROUP).

A great presentation (ppt) that discusses multicast addressing can be downloaded from here.