[Standards] RFC 6120 § 3.3 Reconnection

Peter Saint-Andre stpeter at stpeter.im
Fri Jan 8 23:53:39 UTC 2016


On 1/8/16 4:02 PM, Christian Schudt wrote:
> Hi,
>
> I had a small discussion recently about RFC 6120 § 3.3 Reconnection
> [1].
>
> It states "It can happen that an XMPP server goes offline
> unexpectedly“… and recommends a first reconnection after max. 60
> seconds.

It says to reconnect anywhere from 0 to 60 seconds after being 
disconnected, but not always the same value. What you write below 
("60-seconds truncated binary exponential backoff") implies that the 
spec says always reconnect after 60 seconds, but that's not the 
recommendation.

> We considered this section to not fit the reality, because in reality
> it’s rarely the server,

It might be rare, but when it does happen the reconnection algorithm is 
important because the "thundering herd" of tens of thousands of clients 
all reconnecting at the same time can have a significant impact on 
server performance.

> but far more often the client, which looses
> the connection (e.g. standby mode, closing laptop, mobile phone
> losing connection, etc…) We found waiting for average 30 seconds is
> often too long and poor user experience, because the network is
> usually available faster than that, e.g. after a user reopens its
> laptop and resumes its applications. (e.g. Adium reconnects
> blistering fast after network is available again)
>
> What do you think? Should the 60-seconds truncated binary exponential
> backoff only be applied, if a client has received <system-shutdown/>
> stream error?

I think that's what this section refers to, but making it explicit that 
this is the recommended behavior in the system-shutdown case would be good.

> Can this section be written out more clearly with
> regards to client disconnects?

Remember, if a specification is silent on an issue, then it is up to the 
implementation to do the right thing. So in the case of transient 
network disconnects, I think clients are free to do what makes sense for 
their users.

Peter


More information about the Standards mailing list