[jdev] s2s doubts
Ulrich Staudinger
us at activestocks.de
Wed May 18 08:55:13 CDT 2005
Propably because you subscribed to this mailing list.
Darryl Rhodes schrieb:
>Why am I getting this email?
>
>-----Original Message-----
>From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf
>Of JD Conley
>Sent: Tuesday, May 17, 2005 6:46 PM
>To: Jabber software development list
>Subject: RE: [jdev] s2s doubts
>
>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
>_______________________________________________
>jdev mailing list
>jdev at jabber.org
>http://mail.jabber.org/mailman/listinfo/jdev
>
>________________________________________________________________________
>_____
>Scanned by Sanmina-SCI eShield
>________________________________________________________________________
>_____
>
>
>_______________________________________________
>jdev mailing list
>jdev at jabber.org
>http://mail.jabber.org/mailman/listinfo/jdev
>
>
>
>
More information about the JDev
mailing list