Try OpenEdge Now
skip to main content
Installation and Configuration
NameServer and NameServer Load Balancing Details : Understanding server-level and connection-level fault tolerance : Using NameServer neighbors

Using NameServer neighbors

In a typical environment where UDP broadcasting is used, there is at least one NameServer in each subnet where a Unified Broker exists. A client application that wants to make use of Unified Brokers in each subnet can make a separate connection request to the appropriate controlling NameServer for each Unified Broker. However, NameServer neighbors allow the client to make all of its connection requests using a single NameServer address.
NameServer neighbors are alternate NameServers that you specify as part of a NameServer configuration. When a NameServer receives a connection request from a client that it cannot resolve, it automatically passes the request to the specified NameServer neighbors to attempt the resolution.
NameServer neighbors support client applications in a similar way to replicated NameServers in that the client uses the first response returned by a NameServer, indicating that the requested Application Service was found. However, unlike replicated NameServers, each NameServer neighbor is typically the controlling NameServer for a separate and distinct Unified Broker configuration that might not support the same Application Services as the others.
You can configure each NameServer neighbor as a NameServer with its own set of NameServer neighbors. Thus, you can link NameServer neighbors to other NameServer neighbors for an arbitrary level of depth. You can also replicate both initial NameServers and NameServer neighbors for maximum fault tolerance.
To configure NameServer neighbors:
1. Define the NameServer neighbors as local NameServer instances on your network by using OpenEdge Management or OpenEdge Explorer or by editing the file. These neighbor NameServers can be defined in the same or different subnets in your network.
2. Specify their names as NameServer neighbors when you define the NameServer in OpenEdge Management or OpenEdge Explorer, or assign the names in a comma-separated list as the value of the neighborNameServers property for the definition in the file.
The following figure shows how to configure NameServer neighbors and combines NameServer replication with NameServer neighbors.
Figure 11. NameServer neighbors
In the above figure, if a client requests a connection to a Unified Broker that supports the Inventory Application Service using the broadcast address, the NameServer at host receives the request. If this NameServer has a Unified Broker that registered for the Inventory Application Service, it returns the location of that Unified Broker back to the client. If it does not have a Unified Broker that registered for the Inventory Application Service, this NameServer forwards the request to its neighbors, specified using the broadcast addresses and In this instance, the NameServers at hosts and receive the request.
Note: If you replicate these NameServers, all of the replicated NameServers in each subnet receive the request.
Neither of these NameServers has neighbors of their own, so both of them send a response back to the client. It does not matter if one of the NameServers does not know about the requested Application Service. The client uses the first positive acknowledgement from a NameServer and disregards the rest. The client application only receives an indication that the Application Service was not found if all responding NameServers indicate that the Application Service was not found.
Note that while NameServer neighbors provide the most benefit when using UDP broadcast, there is no requirement to do so. The hostName properties for NS2 and NS3 in the figure can explicitly specify and You might want to use NameServer neighbors without broadcasting when you must tie together preconfigured NameServers, but where the performance implications of broadcasting outweigh the benefits. For more information, see Performance implications of broadcasting.