Why am I getting this email? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [email protected] http://mail.jabber.org/mailman/listinfo/jdev ________________________________________________________________________ _____ Scanned by Sanmina-SCI eShield ________________________________________________________________________ _____ _______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev
