XMPP, Connect Server, and SRV

Sebastiaan Deckers cbas at pandion.be
Fri Oct 17 00:46:16 EDT 2008


On Fri, Oct 17, 2008 at 6:12 AM, Evan Schoenberg <evan.s at dreskin.net> wrote:

>
> *From: *Peter Saint-Andre <stpeter at stpeter.im>
> *Date: *October 14, 2008 12:41:42 PM CDT
> *To: *Mark Doliner <mark at kingant.net>
> *Cc: *"devel at pidgin.im" <devel at pidgin.im>, Evan Schoenberg <
> evan.s at dreskin.net>
> *Subject: **Re: XMPP, Connect Server, and SRV*
>
> Peter Saint-Andre wrote:
>
> Mark Doliner wrote:
>
> On Thu, Sep 18, 2008 at 7:49 PM, Evan Schoenberg <evan.s at dreskin.net>
> wrote:
>
> On Sep 18, 2008, at 11:35 AM, Peter Saint-Andre <stpeter at stpeter.im>
> wrote:
>
> Peter Saint-Andre wrote:
>
> Ethan Blanton wrote:
>
> Bron Gondwana spake unto us the following wisdom:
>
> My idea of the correct behaviour is:
>
>
> a) if an explicit server name is specified, use that always
>
> b) otherwise, lookup up the _jabber._tcp or _xmpp-client._tcp for
>
> the
>
>  domain part of the username.
>
> c) finally, try the A record for the domain part.
>
> I'm pretty sure this is the *current* behavior, unless I
>
> misunderstand
>
> you.
>
> Hmm, it seems that I don't have a) captured in the specs yet:
>
>
> http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-06.html#tcp-resolution
>
> OK, I just added the following text to my working copy:
>
>
>  Note: If the initiating entity has been explicitly configured to
>
>  associate a particular hostname (and potentially port) with the
>
>  original hostname of the receiving entity (say, to "hardcode" an
>
>  association between an original hostname of example.net and a
>
>  configured hostname and of webcm.example.com:80), the initiating
>
>  entity SHALL use the configured name instead of the original name
>
>  when following the resolution process described above.
>
>
> Does that explain scenario (a) more clearly?
>
>
> I remain unclear on whether an SRV lookup should be performed using
>
> the "overridden" server or not.
>
> Sorry to bring up an old thread, I just happened to be looking at it.
>
>
> No, I do not think an SRV lookup should be performed when the
>
> "overridden" server is used.  The "connect server" field is an
>
> alternative to using DNS SRV records.  And it should really only be
>
> used at times when the DNS SRV record can't be used for whatever
>
> reason.
>
>
> I agree. If you did SRV lookups on the SRV lookups, you could get into
>
> an infinite regress. :)
>
>
> Clarified here:
>
> http://is.gd/43Ce
>
> /psa
>
>
Hello everyone,

I've had some off-list discussion with Evan and wanted to state my position
here.

There is never any case of "SRV lookup on the SRV lookups".
Rather the user (eg. j.doe at gmail.com) would specify in the client a hard
coded hostname (eg. talk.google.com) for their XMPP server. The client then
uses SRV resolution on that hardcoded address.
This allows the server to distribute client connections across a cluster
using SRV weights, even if it can't support SRV on its main DNS address.
Without SRV resolution such hard coded address could as not easily be load
shared across nodes.
Of course if the SRV lookup fails on the hard coded address then client will
continue to a regular name lookup.
Am I overlooking some downside to trying SRV lookup on the hard coded
address?

-Sebastiaan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20081017/47ad72d3/attachment.html>


More information about the Devel mailing list