[Pidgin] #9234: XMPP Pings must be made configurable for users

[Pidgin]

#9234: XMPP Pings must be made configurable for users
-------------------------+--------------------------------------------------
 Reporter:  niraj19july  |        Owner:  deryni 
     Type:  defect       |       Status:  pending
Milestone:               |    Component:  XMPP   
  Version:  2.5.6        |   Resolution:         
 Keywords:               |  
-------------------------+--------------------------------------------------
Changes (by deryni):

  * status:  new => pending


Comment:

 We didn't decide that 2 minutes "is okay" we decided 30 seconds was
 unreasonable and two minutes was acceptable as a replacement for 30
 seconds.

 I want to start off by saying that if you are dealing with a server that
 routinely cannot process ping requests within two minutes that you are
 dealing with a server which is *grossly* oversold and should be replaced
 forthwith. Two minutes is an *exceedingly* long time for a basic network
 no-op response.

 The average user *cannot* decide what timeout length is ok, they don't
 have anywhere near the understanding or available information to decide,
 nor should they have to so presenting them with such an option is
 confusing and will just cause them to tweak it incorrectly.

 Disabling pings is not a good idea, it serves no useful purpose. It would
 serve even less useful purpose if our timeout policy was adjusted to
 indicate potential disconnection and/or lag rather than simply
 disconnecting at the first sign of delay.

 TCP timeouts can be *very* long, long enough that they clearly didn't
 solve the normal user usage case which caused the XMPP Ping XEP to be
 written. The XEP was written exactly because most users were unhappy with
 the whitespace ping/TCP timeout mechanisms most clients (including pidgin)
 were previously using. Those pings/timeouts were causing disruptively long
 lag periods between when the connection went dead and when pidgin (and
 therefore the user) noticed it. These lags caused message loss and other
 unpleasant user experiences as well.

 I'm going to skip file transfer for a second to handle the postscript
 comment.

 It is not pidgin's job to keep a server from being overloaded, it is the
 servers job to handle requests in reasonable periods of time (30 seconds
 is unreasonable, we feel that two minutes is not, we would likely be fine
 with a default of 3 minutes as well, possibly even 5, above that we get
 well beyond what most people think of as 'quick' detection of network
 connection loss).

 So the fact that a server is so crippled as to be unable to respond to an
 incredibly basic request within two minutes is an unfortunate fact of an
 overloaded server and not something we need to be working around
 carefully.

 It was not useful to bring file transfers into this discussion because the
 issue here is about ping responses and connection liveliness. File
 transfers are their own pings as we are constantly using the connection
 (in one or both directions). We are not discussing timing out random TCP
 connections.

 Do you have a specific slow server that you deal with frequently? Are you
 seeing ping response related timeout issues yourself? Are you seeing them
 for people you deal with? Or are you suggesting this because you think it
 should exist regardless? Since bumping the timeout to 2 minutes I have
 never been pinged offline incorrectly, and I do not recall hearing any
 complaints about ping timeouts (other than with clearly broken servers).

 I'm still not convinced that we have any issue here other than that we
 'overreact' to ping response timeouts. I've said it before, our kill-
 everything timeout policy is sub-optimal and should definitely be changed,
 I'm just unsure how better to handle it but welcome discussion and
 patches.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/9234#comment:3>
Pidgin <http://pidgin.im>
Pidgin