[jdev] s2s doubts

[Ulrich Staudinger]

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
>
>
>  
>