SRV Records and Spark

We’'ve been using Spark in our organization since whatever the final 1.x version was and are now using Spark 2.x. We have continued to have intermittent, seemingly randomly placed issues with connecting using domain.com listed in the “Server” field of the connect dialog. domain.com has SRV records for xmpp-client.tcp and xmpp-server.tcp set up to point to im.domain.com.

Being that the protocol is supposed to be looking up SRV records first and use the “Server” entry as a fallback, according to my understanding of the standards, this problem is highly frustrating. The JID we have set wildfire up to serve is username@domain.com, not username@im.domain.com.

I’'d rather not have to give up on using domain.com in the “Server” field, as using im.domain.com would be dirty and wrong Am I doing something wrong here?

Anyone? Has anyone even experienced the same thing here?

I have experienced that when upgrading to the latest version of Spark (2.0.3) from 2.0.1. To get 2.0.3 to play nice I just specified the connecting server explicitly in Advanced Connection Preferences.

Being that the protocol is supposed to be looking up SRV records first and use the “Server” entry as a fallback, according to my understanding of the standards, this problem is highly frustrating. The JID we have set wildfire up to serve is username@domain.com, not username@im.domain.com.

That is conceptually incorrect. The “Server” is not a fallback entry or anything like that. It is where you specify the xmpp.domain of the server you’'re connecting to.

During a connection process, Spark will not modify the original JID used, i.e. whatever you specify in the “Username” @ “Server” fields of the connect dialog, regardless of the lookup methods: SRV or fallback. I wonder how you discovered that Spark changed username@domain.com to username@im.domain.com instead.

The SRV->fallback feature does have a side effect however. Suppose you have:

  1. An SRV record for domain.com that points to im.domain.com

  2. An A record that points im.domain.com to ip address 10.10.10.10. This is where you runs Wildfire with xmpp.domain = domain.com (no im infront of it)

  3. An A record that points domain.com to ip address 10.10.10.11. Perhaps this is where you run an HTTP or email server.

With the setup above, your clients should be connecting as username@domain.com. Spark will first try SRV lookup (1)->(2). If that fails, it will try fallback lookup (3). But in (2) and (3) the servers are completely different. This might explain why you continuously get the intermittent and random error. Things will get more confusing if (3) runs another Wildfire with some abitrary xmpp.domain.

I am seeing the same issue… If I type the server’'s exact hostname in the “Server” field on the main logon page, it works… If I just type the daomain name, it fails… All since 2.0.3… And it is not intermittent… It is constant… Across the board, anyone who goes to 2.0.3… And yes I have the SRV records setup… They were working perfectly… Please help… Thanks…

What I meant by “fallback” is that the A record for the entry in the “Server” field is the ‘‘backup’’ to look for when a SRV lookup has failed. All my SRV records are correct as far as I know, and this still happens.

Sorry about that. This was a regression in 2.0.3 to switch over to using compression in the connection. It is fixed in the mainline and 2.0.4 will be released soon.

Cheers,

Derek

Thanks for the update. This relieves a bit of the frustration. This isn’‘t the first time we’'ve had SRV-related issues with Spark, however. Hopefully it will be the last

If I may add a small request…I think it would make much more sense if the “Server” field name was changed to “Domain” or something that better indicates its relation to the XMPP service instead of the server.

I’'ve seen cases where users are confused between “domain” and “xmpp domain”, because an xmpp domain could have a value that very much looks like an IP address, so user@192.168.0.10 is acceptable. I think this might be the reason why some jabber clients do not have “Server” or “Domain” field in their logon screen, but instead force users to enter the full user@xmpp.domain in the “Username” field.

This is a very good point. I think the best combination of “easy” and right would be to have it appear somewhat like so in logon window:


Login Info: usernamebox @ xmppdomainbox

Password: passwordbox


I think this would be a great solution as it both avoids the server/domain/xmpp-domain confusion and presents the JID to the user.

Hi,

Derek did - if I remember the code I did look recently right - already change the code which looks for “@” as the node and domain separator to be LastIndexOf() instead of indexOf() so usernames with “@” should work fine no matter if there is a separate field for the server or not.

LG

What I mean is that the “@” is a static part of the UI…non-editable. Then you have the user enter in the username and xmpp-domain. You then get rid of the need for a confusingly-named Server and/or Domain entry.