Open topic with navigation

TIBCO Rendezvous® 8.8.0

# 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.

Did you find this helpful?

Yes No
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO Rendezvous®

Copyright © 1997-2025. Cloud Software Group, Inc. All Rights Reserved.