Distributed Cache OM : Cache Cluster Discovery

Cache Cluster Discovery
This section explains how the members of the cache cluster can be defined. In many cases, the default multicast values in the provided engine property files work out of the box, with no configuration. Two methods are available: multicast, and well-known-addresses.
Configuration instructions are provided in Configuring a Cache Manager Cluster — Cluster Tab in TIBCO BusinessEvents Administration
When discussing cache clusters, BusinessEvents processing units are also referred to as nodes. The term node is used in the TIBCO BusinessEvents Cache Configuration Guide and in this section.
Cluster Member Discovery Using Multicast Discovery
With multicast cache cluster configuration, the cluster membership is established using the multicast IP address and port. When a BusinessEvents node subscribes to this multicast IP address it broadcasts information about its presence to the address.
Multicast discovery is used by default. The default values provided mean you may not have to configure any discovery-related properties. However, if you deploy multiple BusinessEvents projects in your environment, you must specify different multicast address and port settings for each project.
You can use multicast when instances of an application are deployed to hosts in the same subnet, or across subnets when broadcast is enabled between the subnets.
Adding, Removing, and Moving Nodes
The object management layer uses multicast to discover new nodes and add them to the cache cluster. Similarly when nodes are removed or moved to a different server, the multicast protocol ensures that members are kept current without any additional configuration.
For the above reason, multicast discovery requires less maintenance than the well-known-address method, which requires configuration updates for all such changes.
Network Traffic
When multicast discovery is used, network traffic is generated by the following activities:
Cluster heartbeat  The most senior member in the cluster issues a periodic heartbeat using multicast. The rate is configurable and defaults to one per second.
Message delivery  Messages intended for multiple cluster members are often sent using multicast, instead of unicasting the message one time to each member.
For peer-to-peer communications and data transfer, the object management layer then uses unicast as needed. Peer-to-peer connections are automatically established with other servers listening on the multicast address.
Cluster Member Discovery Using Well-Known-Addresses
Well-known-address configuration uses direct member-to-member (point-to-point) communication, including messages, asynchronous acknowledgements (ACKs), asynchronous negative acknowledgements (NACKs) and peer-to-peer heartbeats. The addresses are "well known" to the extent that they are known to each server in the cluster.
Use well-known-addresses instead of multicast to define the cluster participants when multicast is undesirable or unavailable, for example, if nodes are deployed to different subnets and broadcast between the subnets is not enabled.
Adding, Removing, and Moving Nodes
You must ensure that the well known address information is updated on all machines to account for system changes, such as adding, removing, and moving nodes to different machines.
If a machine changes name or IP address, the cluster continues to work correctly until the next time you restart that machine.
Discovery When Host Machines Have Multiple Network Cards
If a host machine has multiple network cards, you must specify which IP address and port to bind to. To do this you use localhost and localport properties.
Do this whether you are using multicast or well-known-addresses to define the cache cluster.