Subject: [xmpp] #11: specify rules regarding reconnection to same IP address or hostname

From: "xmpp issue tracker" <[email-masked]>
Date: Mon, 14 Jun 2010 17:46:44 -0000

#11: specify rules regarding reconnection to same IP address or hostname
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 Dave Cridland commented as follows regarding Section 3.4 (Reconnection):

 "I vaguely recall some discussion about reconnecting to the same IP
 address, and/or hostname, before performing a full SRV rediscovery."

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/11>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Jun 2010 20:08:11 -0600

> #11: specify rules regarding reconnection to same IP address or hostname

That text is in Section 3.4 (Reconnection):

   o  The time to live (TTL) specified in Domain Name System records
      SHOULD be honored, even if DNS results are cached; if the TTL has
      not expired, an entity that seeks to reconnect SHOULD NOT re-
      resolve the server hostname before reconnecting.

/psa

---

From: "xmpp issue tracker" <[email-masked]>
Date: Fri, 25 Jun 2010 02:09:14 -0000

#11: specify rules regarding reconnection to same IP address or hostname
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |        Owner:  stpeter@…         
     Type:  defect              |       Status:  closed            
 Priority:  minor               |    Milestone:                    
Component:  3920bis             |      Version:                    
 Severity:  In WG Last Call     |   Resolution:  invalid           
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by stpeter@…):

  * status:  new => closed
  * resolution:  => invalid

Comment:

 This issue is addressed by text in Section 3.4.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/11#comment:1>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Kevin Smith <[email-masked]>
Date: Fri, 25 Jun 2010 08:30:36 +0100

>      resolve the server hostname before reconnecting.

I'm sorry I didn't catch this first time around - this text causes
problems for people on laptops moving networks (or even people on
desktops with VPNs etc.). Experience says that clients end up getting
DNS caching reported as a bug, because it breaks reconnection for a
significant number of people, so I'd propose removing this block
completely (especially noting that DNS lookups aren't hitting the XMPP
service itself, which is what this section seems to be protecting).

/K

---

From: Dave Cridland <[email-masked]>
Date: Fri, 25 Jun 2010 10:52:15 +0100

> > #11: specify rules regarding reconnection to same IP address or  

Ah, no, more than that.

Let's suppose there are two equal weight, equal priority records:

_xmpp-client._tcp SRV 5 5 5222 hermes.example.org.
_xmpp-client._tcp SRV 5 5 5222 apollo.example.org.

According to the rules in §3.4, if we've been connected to Hermes  
and we lose connection, we should randomly pick from hermes and  
apollo, with a 50% probability of either.

I recall some (sensible-sounding) discussion that attempting to  
reconnect to the hermes without making that random selection is  
reasonable and useful, as it might allow cached resources, XEP-0198,  
etc to be more efficient.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 25 Jun 2010 15:22:09 -0600

On 6/25/10 3:52 AM, Dave Cridland wrote:
> According to the rules in §3.4, if we've been connected to Hermes and we
> lose connection, we should randomly pick from hermes and apollo, with a
> 50% probability of either.
> 
> reasonable and useful, as it might allow cached resources, XEP-0198, etc
> to be more efficient.

Either your memory is better than mine or your imagination is more
active. :) I don't recall text along those lines, but the concept seems
reasonable so feel free to formulate some text for consideration.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 27 Jun 2010 13:50:54 -0600

On 6/25/10 1:30 AM, Kevin Smith wrote:
> desktops with VPNs etc.). 

I'm not convinced of that, but that's immaterial.

> Experience says that clients end up getting
> significant number of people, 

I have not seen that in the wild.

> so I'd propose removing this block

I agree that we're not protecting any XMPP entities here (only hitting
DNS servers more often), so it seems reasonable to remove that paragraph
and in the Reconnection section talk only about XMPP communications.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Kevin Smith <[email-masked]>
Date: Sun, 27 Jun 2010 21:32:57 +0100

> I'm not convinced of that, but that's immaterial.

For the sake of clarity, the scenario is something like:
You fire up your laptop at work, and the company split-horizon DNS
says that your server is 192.168.0.52, you leave the office and
192.168.0.52 doesn't exist any more.

> I have not seen that in the wild.

It has been true for both Psi and Swift, I wouldn't know if devs on
other projects have had similar reports - it could be these are the
only two :)

> and in the Reconnection section talk only about XMPP communications.

Thanks.

/K