Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Note you could have several SRV records to specify failover/redundancy or whatever:

{{
_xmpp-server._tcp.example.com. 86400 IN SRV 10 50 5269 wave1.example.com.
_xmpp-server._tcp.example.com. 86400 IN SRV 10 50 5269 wave2.example.com.
_xmpp-server._tcp.example.com. 86400 IN SRV 20 0 5269 backup-wave.example.com.
}}

A Records

Every 'Target' of an SRV should have an appropriate A record in DNS, so that the server can resolve the name to an IP address. In the example above, you would need to assure that wave.example.com had a valid record, and could be resolved externally.

...

First, acmewave.com needs to be able to look up your server via DNS, so you will need to configure A records for example.com and wave.example.com that point to your server. How you set that up is particular to your ISP and domain name provider so we can't give detailed instructions on how to set this up, but there is a command line program to use to determine if you do have it set up correctly: dig. You can run dig and if each of the following return a good IP address then you are in good shape (substitute in your domain name on the command line).

{{
$ dig +short -t A example.com
72.148.43.48
$ dig +short -t A wave.example.com
72.148.43.48
}}

Note that you need both your domain name, and the wave sub-domain to resolve via DNS.

...

This is just the standard algorithm that XMPP uses to find another server, it prepends xmpp-server.tcp to the domain name and then looks up the SRV record to find out the port and domain name of the server it needs to connect to. Remember to set up SRV records for both _xmpp-server._tcp.example.com and _xmpp-server._tcp.wave.example.com. Also note that the trailing "." isn't a typo, you will need that. To test that you have everything setup properly you can again use dig:

{{
$ dig +short -t SRV _xmpp-server._tcp.example.com
10 0 5269 example.com.
$ dig +short -t SRV _xmpp-server._tcp.wave.example.com
10 0 5269 example.com.
}}

Testing

Once you have that all configured you can now test federation. Edit run-server.sh and set the ping server to {{acmewave.com}:

{{
...
--xmpp_server_ping="acmewave.com" \
...
}}

Now when you start up the server you should see your server ping acmewave.com and then acmewave.com should send back a packet:

{{
$ ./run-server.sh
.
.
.
Aug 26, 2009 7:02:47 PM org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent processPacket
INFO: received XMPP packet:

<message type="normal" id="4191-2" from="wave.acmewave.com" to="wave.example.com">
<received xmlns="urn:xmpp:receipts"/>
</message>
Aug 26, 2009 7:02:47 PM org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent processMessageReceipt
INFO: got ping response from acmewave.com

<message type="normal" id="4191-2" from="wave.acmewave.com" to="wave.example.com">
<received xmlns="urn:xmpp:receipts"/>
</message>
}}

Chatting

To chat you can now go back and run the client:

...

And from within the client create a new wave and add a participant from another federated server:

{{
/new
/open 0
/add thorogood@acmewave.com
}}

If that user is available they can now chat with you. Server details and times that people are available are posted to the wave-protocol mailing list. Post yours too and help test federation.

*TODO: console client still available? Change mailing list to apache-dev?