Programming Jabber

Host filter

The diagram shown in Figure 4-3 states "none specified" for the host specification—the host filter. So what happens now? Well, a host filter is usually one or more <host/> tags containing hostnames to which the component instance will “answer.” It’s a way of specifying that packets destined for a certain hostname will be received by that component instance.

However, if there are no <host/> tags specified as in this c2s example, then the component instance’s identification is taken as the hostname specification. In other words, the <service id="c2s"> declaration in this example, coupled with the lack of any explicit <host/> tag, implies a host filter of c2s. This component instance wants to receive all packets with addresses that have c2s as the hostname. It’s the equivalent of this host filter specification:

<host>c2s</host>

Packets and Hostnames

Each packet traveling within the Jabber universe has a destination address, in the form of a JID, which at the very least contains a hostname specification. This hostname can be a “real” hostname in the DNS sense, or it can be a Jabber-internal hostname, such as jud.yak.

When you send a packet, such as a <message/> element from your Jabber client, you’re sending it as an XML fragment within the context of the jabber:client XML stream running between your client and the Jabber server. Apart from the initial activity to connect to the Jabber server’s listening socket, there’s no hostname resolution on the client’s part—the ...