3 ms·

> You would tell your client to connect to "google.com" and it was hardcoded to connect to "xmpp.google.com", with no option to choose a different server. >If

> You would tell your client to connect to "google.com" and it was hardcoded to connect to "xmpp.google.com", with no option to choose a different server. >If you had multiple domains that you wanted to connect the servers would also default to xmpp.other.domain. This seems strange. XMPP has SRV records specified for discovery of the client endpoint, so the "correct" thing for a client to do would be to look up the xmpp-client SRV record for your domain and attempt to connect to that. It's possible that some clients had a fallback to prepend "xmpp" to the domain, but I'm not aware that that's ever been standard practice - more commonly they'll fall back to an A record lookup on the domain part of the account. >The whole thing assumed the entire domain would be served by one single server Certainly not. Clients will (or should, anyway) try connecting to servers based on their priority/weight in the SRV record: https://xmpp.org/rfcs/rfc6120.html#tcp-resolution-prefer https://xmpp.org/rfcs/rfc6120.html#tcp-resolution-prefer As GP mentioned, this does assume that you have servers capable of scaling horizontally, because XMPP is stateful. Not all can, but some do.

jandrese 7y ago
It's what Jabber used to do back in the day at the least.
- vertex-four 7y ago
  Basically, the assumption is that you have your SRV records set up properly. Modern XMPP clients, like Dino, will then reconnect automatically to a server that they can access, and read history to find anything they missed. Horizontally scaling XMPP servers exist, it's probably up to you to find one that works well in a multi-site configuration though. Your other option is just to give everyone their own XMPP address on a subdomain for each site - foo@dublin.example.com, bar@brussels.example.com, etc. I do this with a number of independent XMPP servers and it works fine. Then you're just depending on ordinary XMPP s2s to communicate between them, which is obviously well-supported.
  - jandrese 7y ago
    But again, if you're not the domain admin you are pretty much SOL. It's not a friendly technology for the hobbyist.
    - vertex-four 7y ago
      The hobbyist is the domain admin. What situation are you thinking of where they're not? It's not a friendly technology for enterprises where it might take weeks to add a DNS record, maybe. But nor is much else.
      - SamWhited 7y ago
        Yah, if you're using this for enterprise though you probably have to jump through all the hoops either way. Eg. to provision and install a client (be it some general XMPP client, slack, hipchat server, whatever) on your dev machines, to provision machines for a server and get that setup or to contract it out to someone, and yes, finally, to setup DNS records. So I don't think it's a big deal that DNS records are required for enterprise, they're going to have to keep a papertrail and do all the extra overhead anyways. :)
    - SamWhited 7y ago
      For the hobbiest there are also other ways, eg. using HTTP and a JSON/XML file on the server. Eg see https://xmpp.org/extensions/xep-0156.html https://xmpp.org/extensions/xep-0156.html DNS SRV is just the easiest (IMO) and most widely supported method, so I generally recommend just doing that since you probably have DNS anyways, even if you don't necessarily have an HTTP server running on your chat machine.

jandrese 7y ago

It's what Jabber used to do back in the day at the least.

vertex-four 7y ago
Basically, the assumption is that you have your SRV records set up properly. Modern XMPP clients, like Dino, will then reconnect automatically to a server that they can access, and read history to find anything they missed. Horizontally scaling XMPP servers exist, it's probably up to you to find one that works well in a multi-site configuration though. Your other option is just to give everyone their own XMPP address on a subdomain for each site - foo@dublin.example.com, bar@brussels.example.com, etc. I do this with a number of independent XMPP servers and it works fine. Then you're just depending on ordinary XMPP s2s to communicate between them, which is obviously well-supported.
- jandrese 7y ago
  But again, if you're not the domain admin you are pretty much SOL. It's not a friendly technology for the hobbyist.
  - vertex-four 7y ago
    The hobbyist is the domain admin. What situation are you thinking of where they're not? It's not a friendly technology for enterprises where it might take weeks to add a DNS record, maybe. But nor is much else.
    - SamWhited 7y ago
      Yah, if you're using this for enterprise though you probably have to jump through all the hoops either way. Eg. to provision and install a client (be it some general XMPP client, slack, hipchat server, whatever) on your dev machines, to provision machines for a server and get that setup or to contract it out to someone, and yes, finally, to setup DNS records. So I don't think it's a big deal that DNS records are required for enterprise, they're going to have to keep a papertrail and do all the extra overhead anyways. :)
  - SamWhited 7y ago
    For the hobbiest there are also other ways, eg. using HTTP and a JSON/XML file on the server. Eg see https://xmpp.org/extensions/xep-0156.html https://xmpp.org/extensions/xep-0156.html DNS SRV is just the easiest (IMO) and most widely supported method, so I generally recommend just doing that since you probably have DNS anyways, even if you don't necessarily have an HTTP server running on your chat machine.