4 ms·

That sounds like a server design problem, not a client problem. XMPP is stateful, so it is harder to have a distributed server but it's also doing something mor

That sounds like a server design problem, not a client problem. XMPP is stateful, so it is harder to have a distributed server but it's also doing something more complicated than eg. serving a document like HTTP. If you use a server like ejabberd and a proxy layer you can easily do geographic distribution of the server, or at least, with no more difficulty than any other protocol.

jandrese 7y ago
It bled over into clients too. 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. If you wanted to connect to test.my.domain to test2.my.domain you were SOL. In a lab environment you could hack it with local DNS fuckery, but to actually deploy it would have been a nightmare. The whole thing assumed the entire domain would be served by one single server and all clients would always have good connectivity. Their old IRC model was just to have a local server at each site with a cache. When the network went down (which it did frequently), the local users would still have connectivity, and when the link came back up they would get the backscroll. Replicating this sort of config with XMPP turned out to be very difficult, and eventually the bosses relented and let them keep IRC, or at least they passed the problem off to someone else after I left.
- ryukafalz 7y ago
  > 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. :)
- seba_dos1 7y ago
  Google Talk never really followed any standard way of specifying the server that handled the domain. This is a non-issue these days.
- aidenn0 7y ago
  That was not the case since at least 15 years ago; that's when I setup a couple of jabber servers on subdomains. None of them had xmpp in their DNS name.
- SamWhited 7y ago
  It hasn't been this way for a while (since the early 2000s, I think), most things lookup DNS SRV records now, and before that most things provided a field to enter a different server address.

jandrese 7y ago

It bled over into clients too. 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. If you wanted to connect to test.my.domain to test2.my.domain you were SOL. In a lab environment you could hack it with local DNS fuckery, but to actually deploy it would have been a nightmare. The whole thing assumed the entire domain would be served by one single server and all clients would always have good connectivity. Their old IRC model was just to have a local server at each site with a cache. When the network went down (which it did frequently), the local users would still have connectivity, and when the link came back up they would get the backscroll. Replicating this sort of config with XMPP turned out to be very difficult, and eventually the bosses relented and let them keep IRC, or at least they passed the problem off to someone else after I left.

ryukafalz 7y ago
> 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. :)
seba_dos1 7y ago
Google Talk never really followed any standard way of specifying the server that handled the domain. This is a non-issue these days.
aidenn0 7y ago
That was not the case since at least 15 years ago; that's when I setup a couple of jabber servers on subdomains. None of them had xmpp in their DNS name.
SamWhited 7y ago
It hasn't been this way for a while (since the early 2000s, I think), most things lookup DNS SRV records now, and before that most things provided a field to enter a different server address.