Programming Jabber

Custom Configuration

The dnsrv component provides hostname lookup and dynamic routing services. To this end, the configuration concerns itself with defining how the routing is to be determined.

The configuration, identified with the jabber:config:dnsrv namespace, contains a list of entries that describe service types and next-delivery-point data. What does this mean? In hostname resolution, a lookup request can be made where a service and protocol, as well as a domain name, are specified. When more than one server shares the same domain name and services (such as Jabber) are managed across the servers, different host addresses can be returned, depending on the service requested. So far, so good; the resolution part of the deal is covered. But what happens once an IP address has been returned? The packet destined for the nonlocal component must be sent on its way—but via where? This is what the next-delivery-point data specifies.

If we examine the configuration, we see this:

<dnsrv xmlns="jabber:config:dnsrv">
  <resend service="_jabber._tcp">s2s</resend>
  <resend>s2s</resend>
</dnsrv>

The configuration is a list of services to try for during the resolution request. This list has two items. The first has the service="_jabber._tcp" attribute that says, “Try for the Jabber (via TCP) service when trying to resolve a name (using a SRV record lookup request) and, if successful, send the packet to the s2s component.” The second is the default that says, “If you’ve reached here in ...