Multicast Addressing
Multicast addressing is a focused broadcast capability implemented at the operating system level. In the same way that the Rendezvous daemon filters out unwanted messages based on service groups, multicast hardware and operating system features filter out unwanted messages based on multicast addresses.
When no broadcast messages are present on the service, multicast filtering (implemented in network interface hardware) can be more efficient than service group filtering (implemented in software). However, transports that specify multicast addressing still receive broadcast messages, so combining broadcast and multicast traffic on the same service can defeat the efficiency gain of multicast addressing.
Rendezvous software supports multicast addressing only when the operating system supports it. If the operating system does not support it, and you specify a multicast address in the network argument, then transport creation calls produce an error status (TIBRV_NETWORK_NOT_FOUND).
Limitation on Computers with Multiple Network Interfaces
On computers with more than one network interface, Rendezvous programs must not attempt to combine communications over different network interfaces using the same UDP service. To understand this limitation, consider these examples of incorrect usage in the context of multiple network interfaces.
Erroneous Examples
| • | A program, mylistener, creates a transport using service 7500 and network lan0; it listens to broadcast subjects using that transport. Other program processes on both lan0 and lan1 send broadcast messages using service 7500. |
As a result, mylistener might unexpectedly receive inbound messages from lan1.
| • | An administrator configures the Rendezvous routing daemon on a computer with two network interfaces (lan0 and lan1) using service 7500. Since the administrator does not specify a -network parameter, the routing daemon uses the default network interface. |
As a result, the routing daemon forwards messages from its neighbor only to the default network interface; however, it might forward messages from both lan0 and lan1 to its neighbor.
| • | A program creates two network transports. Both use service 7500, but one uses network lan0, while the other uses network lan1. |
As a result, the call to create the second transport produces an error.
| • | Two programs on the same computer each create a transport. Both use service 7500, but one uses network lan0, while the other uses network lan1. Even though these transports are in different processes, both transports connect to the same Rendezvous daemon—which is subject to the limitation. |
As a result, the program fails to create the second transport.
We recommend caution when you deploy Rendezvous programs or Rendezvous routing daemons on any computer with multiple network interfaces.
Source of the Limitation
The roots of this limitation are in the underlying IP broadcast protocols. Consider this asymmetry:
| • | When sending an outbound broadcast packet, IP software sends the packet on exactly one network. |
Rendezvous programs can specify this network with the transport creation function’s network parameter.
| • | In contrast, IP software collects inbound broadcast packets from all network interfaces. |
Furthermore, when IP software presents an inbound packet to a client program (such as rvd) it does not include any indication of the network on which that packet arrived.
Because of this asymmetry, the actual behavior of IP broadcast protocols can be different than one might expect.
Avoiding the Limitation
You can use two strategies to avoid problems associated with this limitation:
| • | Use a separate service for Rendezvous messages on each network. |
| • | Use multicast addressing to precisely define a range of reachable transports. |
Using a separate service can rectify all four of the erroneous examples. Multicast addressing can rectify the first two erroneous examples, but not the latter two. In all four examples, a single Rendezvous daemon is sufficient.
For example, consider these two approaches to rectifying the first erroneous example:
| • | Separate Service |
A program, mylistener, creates a transport using service 7500 and network lan0; it listens to broadcast subjects using that transport. Other processes on lan0 send messages using service 7500, but all processes on lan1 send messages using service 7510. Separating by service prevents the transport from receiving interference from lan1.
| • | Multicast Addressing |
A program, mylistener, creates a transport using service 7500 and multicast network lan0;225.1.1.1. This transport selectively receives only those inbound multicast messages that are sent on network lan0, to multicast address 225.1.1.1, on service 7500. Multicast addressing (where available) filters out messages sent on other networks using any other multicast address.
However, multicast addressing does not filter out IP broadcast messages sent on the same UDP service. Once again, the roots of this limitation are in the underlying IP broadcast protocols.