Provisioning Bandwidth for Multicast

Multicast installations require much more planning and configuration than TCP installations. By choosing IP multicast, you gain scalability but lose the administrative convenience of TCP. When you install an application that runs over TCP, the network is almost always set up for TCP and other applications are already using it. When you install an application to run over IP multicast it may be the first multicast application on the network.

Multicast is very dependent on the environment in which it runs. Its operation is affected by the network hardware, the network software, the machines, which GemFire processes run on which machines, and whether there are any competing applications. You could find that your site has connectivity in TCP but not in multicast because some switches and network cards do not support multicast. Your network could have latent problems that you would never see otherwise. To successfully implement a distributed GemFire system using multicast requires the cooperation of both system and network administrators.

Bounded Operation Over Multicast

Group rate control is required for GemFire systems to maintain cache coherence. If your application delivers the same data to a group of members, your system tuning effort needs to focus on the slow receivers.

If some of your members have trouble keeping up with the incoming data, the other members in the group may be impacted. At best, slow receivers cause the producer to use buffering, adding latency for the slow receiver and perhaps for all of them. In the worst case, throughput for the group can stop entirely while the producer’s CPU, memory and network bandwidth are dedicated to serving the slow receivers.

To address this issue, you can implement a bounded operation policy, which sets boundaries for the producer’s operation. The appropriate rate limits are determined through tuning and testing to allow the fastest operation possible while minimizing data loss and latency in the group of consumers. This policy is suited to applications such as financial market data, where high throughput, reliable delivery and network stability are required. With the boundaries set correctly, your producer’s traffic cannot cause a network outage.

Multicast protocols typically have a flow control protocol built into them to keep processes from being overrun. The GemFire flow control protocol uses the mcast-flow-control property to set producer and consumer boundaries for multicast flow operations. The property provides these three configuration settings:


Number of bytes that can be sent without a recharge.


Tells consumers how low the producer’s initial to remaining allowance ratio should be before sending a recharge.


Tells the producer how long to wait for a recharge before requesting one.