[jdev] s2s doubts

JD Conley jd.conley at coversant.net
Tue May 17 18:45:41 CDT 2005


Sounds like you're having fun with S2S. Make sure you test with all the
implementations out there and with subdomains on all of them.  For
example, make sure you S2S to jabber.org and also conference.jabber.org
and make a two way connection happen.  Do the same for any other servers
you wish to be compatible with.  They all have their quirks. :)

> Lets suppose that server1 has successfully accepted a connection with
> server2 using server dialback. If a client sends a message to server1
with
> TO=conference.server2, does server1 have to send the packet to server2
> assuming that conference.server2 is handled by server2? Or does
server2
> need
> to inform server1 that that subdomain is valid?

Server1 should connect to conference.server2.  S2S does not make any
considerations for sub domains.

However, many servers will re-use the existing TCP connection for the
sub domain if both resolve to the same IP.  This is especially true for
the actual dialback connection.  Instead of establishing a new
connection and stream, they will simply send in a new db packet to setup
the dialback connection for the other domain (like you mentioned below).
I believe J2 does this, at least. 

> Is it correct to create the second connection
> after
> the first connection was established? I guess this is an
implementation
> decision but I would like to know if that is the standard way of doing
it.

This is an implementation decision.  In our server we chose to not
establish the other connection until it is needed.  Obviously you have
to establish a connection for the dialback, but it is thrown away.  From
what I've seen this is standard practice.

> What happens to the first connection if the second connection fails to
be
> established? What happens to the other connection if one connection
goes
> down? I assume that the remaining connection will be used and that the
> server will try to regenerate the other connection. 

The connections should be treated independently.  Also, connections will
"go down" all the time.  Most servers have idle timers and will drop S2S
connections if they haven't been used in a while.  Others will send keep
alive packets (XML whitespace) and keep the connection alive.  This is
also configurable in some servers.

> Is it necessary to have 2 connections when using TLS/SASL?

I remember this being a topic of debate last year.  Since you can do
mutual verification with TLS certs this answer is technically "no".  In
our implementation I believe we use just one connection and require
mutual certificate verification.  However, I believe you are supposed to
establish two connections.

> After successful dialback negotiation, the Receiving Server SHOULD
accept
> subsequent <db:result/> packets (e.g., validation requests sent to a
> subdomain or other hostname serviced by the Receiving Server) from the
> Originating Server over the existing validated connection; this
enables
> "piggybacking" of the original validated connection in one direction.
Is
> this being used for "registering" subdomains/services or virtual hosts
> with
> the Receiving Server? 

This is just a shortcut to re-use existing TCP channels when domains
resolve to the same IP.  For example we host soapbox.net, coversant.net,
conference.soapbox.net, conference.coversant.net on our server.  It
would be a bit wasteful for jivesoftware.com to establish an outgoing
dialback connection for all of those domains when they are on the same
system.

> If the answer is yes then how do you implement the
> same thing using TLS/SASL? If the Originating Server never registered
> other
> subdomains is it valid to assume that "conference.server2 is handled
by
> server2" (see first question)?

TLS/SASL requires a separate connection per domain since XMPP makes no
provisions for establishing streams to multiple domains over the same
connection.  Opening a stream within a stream is prohibited.

Hope this helps.

-JD



More information about the JDev mailing list