The discovery mechanisms defined in this standard are expected to be used in many different network architectures. The following three architectures are Illustrated:

• Single MulticastSubnet;
• Multiple MulticastSubnets;
• No MulticastSubnet (or multiple MulticastSubnets with exactly one host each);

A MulticastSubnet is a network segment where all hosts on the segment can receive multicast packets from the other hosts on the segment. A physical LAN segment is typically a MulticastSubnet unless the administrator has specifically disabled multicast communication. In some cases multiple physical LAN segments can be connected as a single MulticastSubnet

The Single MulticastSubnet Architecture is shown in Figure 8.

Figure 8 – The Single MulticastSubnet Architecture

In this architecture every host has an LDS-ME and uses mDNS to maintain a cache of the applications on the MulticastSubnet. A Client can call FindServersOnNetwork on any LDS-ME and receive the same set of applications. When a Client calls FindServers it only receives the applications running on the same host as the LDS.

The Multiple MulticastSubnet Architecture is shown in Figure 9.

Figure 9 – The Multiple MulticastSubnet Architecture

This architecture is the same as the previous architecture except in this architecture the mDNS messages do not pass through routers connecting the MulticastSubnets. This means that a Client calling FindServersOnNetwork will only receive a list of applications running on the MulticastSubnets that the LDS-ME is connected to.

A Client that wants to connect to a remote MulticastSubnet shall use out of band discovery (i.e. manual entry) of a HostName or DiscoveryUrl. Once a Client finds an LDS-ME on a remote MulticastSubnet it can use FindServersOnNetwork to discover all applications on that MulticastSubnet.

The No MulticastSubnet Architecture is shown in Figure 10.

Figure 10 – The No MulticastSubnet Architecture

In this architecture the mDNS is not used at all because the Administrator has disabled multicast at a network level or by turning off multicast capabilities of each LDS-ME.

A Client that wants to discover a applications needs to use an out of band mechanism to find the HostName and call FindServers on the LDS of that host. FindServersOnNetwork may also work but it will never return more than what FindServers returns.

The mDNS specification requires that fully qualified domain name be annouced on the network. If a Server is not configured with a fully qualified domain name then mDNS requires that the ‘local’ top level domain be appended to the domain names. The ‘local’ top level domain indicates that the domain can only be consided to be unique within the subnet where the domain name was used. This means Clients need to be be aware that URLs received from any LDS-ME other than the one on the Client’s machine could contain ‘local’ domains which are not reachable or will connect to a different machine with the same domain name that happens to be on the same subnet as the Client. It is recommended that Clients ignore all URLs with the ‘local’ top level domain unless they are returned from the LDS-ME running on the same machine.

System administrators can eliminate this problem by configuring a normal DNS with the fully qualilfied domain names for all machines which need to be accessed by Clients outside the MulticastSubnet.

Servers configured with fully qualified domain names should specify the fully qualified domain name in its ApplicationInstance Certificate. Servers shall not specify domains with the ‘local’ top level domain in their Certificate. Clients using a URL returned from an LDS-ME shall ignore the ‘local’ top level domain when checking the domain against the Server Certificate.

Note that domain name validation is a necessary but not sufficient check against rogue Servers or man-in-the-middle attacks when Server Certificates do not contain fully qualified domain names. The Certificate trust relationship established by administrators is the primary mechanism used to protect against these risks.