The common location lookup mechanism for IM2000 services

In order to locate a particular IM2000 service on Internet, clients may be supplied a domain name. In order to locate the relevant server using that domain name, they perform SRV lookups in the public DNS database, using a variation on the RFC 2782 algorithm.

The service location algoritmn

  1. The client prepends the service name (which is defined for each individual service) and the protocol name (_TCP) labels to the supplied domain name to form the DNS question domain name.

  2. The client performs a DNS database lookup for the SRV resource record set, of the IN class, for that question domain name.

  3. If an answer cannot be obtained, the client takes the service to be temporarily unlocatable and exits the algorithm. Otherwise the client then processes the answer:

    1. If the question domain name does not exist, the client takes the service to be permanently unreachable and exits the algorithm.

    2. If the resource record set is empty (i.e. it contains no SRV resource records), the client takes the service to be temporarily unlocatable and exits the algorithm.

    3. The client sorts the list of resource records into priority order. It then proceeds to process each group of resource records that have the same priority, in ascending priority order:

      1. The client orders the resource records in the group according to weight.

      2. While the group remains non-empty:

        1. The client removes a resource record from the group using the weighted selection algorithm described in RFC 2782.

        2. The client performs the A, AAAA, and equivalent IP address DNS lookups on the target domain name of the removed resource record.

        3. If the target domain name does not exist or has an empty set of IP addresses, the client continues to removing the next resource record from the group.

        4. If the target domain name exists and has a non-empty set of IP addresses, the client sorts the set using local criteria (DNS lookup functions may do this implicitly.) and attempts to contact the service on each IP address and TCP port number in turn until a connection is made.

        5. If the client was able to connect to the service (irrespective of whether it was able to actually communicate using the relevant protocol), it exits the algorithm.

Notes on this algorithm


© Copyright 2004-2004 Jonathan de Boyne Pollard. All rights reserved. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp information is preserved.