Subject: [xmpp] Reconnection for clients

From: Kevin Smith <[email-masked]>
Date: Mon, 7 Jun 2010 10:17:54 +0100

3.4
"      Implementation Note: Because it is possible that a disconnected
      entity cannot determine the cause of disconnection (e.g., because
      there was no explicit stream error) or does not need a new stream
      for immediate communication (e.g., because the stream was idle and
      therefore timed out), it SHOULD NOT assume that it needs to
      reconnect immediately."

I think this is only true for s2s; c2s probably SHOULD reconnect
immediately, even if it was previously idle (because unlike s2s, the
server can't cause a reconnect when it has pending data).

/K

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 8 Jun 2010 02:30:09 +0900

Hi,

> server can't cause a reconnect when it has pending data).

There is an issue in proposing to reconnect immediately. If the
disconnection has happened to many (server issue, maintenance,
whatever), if not all, clients at once, they would all try to
reconnect in the same time as soon as the server is up again. So it
would cause traffic jam issues, or worse.

If I remind well, there is a passage in the RFC about this issue with
a proposed algorithm (including a time randomization before
reconnection try).
So even C2S should not try to reconnect immediately.
Bye.

Jehan

---

From: Kevin Smith <[email-masked]>
Date: Mon, 7 Jun 2010 18:41:49 +0100

> So even C2S should not try to reconnect immediately.

This isn't taken from the section about backing off on subsequent
reconnect attempts (that's covered elsewhere).

This is just talking about not re-opening the stream until you have
stuff to send, which is right for s2s and wrong for c2s.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 07 Jun 2010 15:28:05 -0600

> server can't cause a reconnect when it has pending data).

One scenario: a client might have had an idle connection, the user
tripped over a network cable while running out the door, now there is no
user at the device so why reconnect?

But how helpful is this implementation note in the first place?

/psa

---

From: Kevin Smith <[email-masked]>
Date: Mon, 7 Jun 2010 22:48:39 +0100

> user at the device so why reconnect?

Well, in that scenario the user still probably wants their client
reconnected - they'll have messages waiting for them when they get
back, MUC logs to read, pubsub notifications or whatever. If they
connected in the first place, they probably want to stay connected.

> But how helpful is this implementation note in the first place?

Questionable.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 07 Jun 2010 15:52:48 -0600

>> But how helpful is this implementation note in the first place?

So why not remove it, I ask. :)

/psa

---

From: Matthew Wild <[email-masked]>
Date: Tue, 8 Jun 2010 00:16:25 +0100

> So why not remove it, I ask. :)

I don't think it would hurt to remove it. Possibly in that section add
an "if an entity chooses to reconnect then [...]", or similar wording
to suggest that reconnection isn't mandatory.

Matthew

---

From: Dave Cridland <[email-masked]>
Date: Tue, 08 Jun 2010 11:06:48 +0100

> user at the device so why reconnect?
There is a user at the device, because they must have come back into  
the room to plug the cable back in.

See the flaw in your logic?

But really, if the user doesn't want to be connected, they'll  
disconnect as they leave, rather than switch to away.

Connection is a state, not an event.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Jun 2010 19:24:47 -0600

> to suggest that reconnection isn't mandatory.

Done.

Peter

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