On Tue, Jul 19, 2011 at 9:13 PM, Matthew A. Miller < [email protected]> wrote:
> Sending at that rate will result in a disconnected socket for most of the > networks I've seen. There are still an exorbitant number of routers, > proxies, firewalls, and load balancers deployed and configured such that > they will (silently!) drop a connection if there is no traffic for 5-10 > minutes. > I've never encountered a network that'll disconnect with 10-15-minute keepalives; there may be some, but I doubt "most". A number of clients will send a keepalive (whitespace or otherwise) every > 60-120 seconds; a number of server deployments will send their own at > roughly the same rate. This is great for desktops, but less than ideal for > mobile. > But, this doesn't require negotiation. If a client needs to send keepalives more frequently (due to broken routers) or less frequently (battery life), it doesn't need to discuss that with the server; it can just do it. If a server is unfortunate enough to be behind broken software that drops connections too quickly, it can likewise adjust its own keepalive interval to compensate, without any negotiation; otherwise it should send them infrequently (if at all). Servers shouldn't be sending keepalives every 60-120 seconds. This just seems like an overcomplication that isn't likely to actually negotiate values that make sense. It also seems to assume that the client and server will always send keepalives at the same rate. (Of course, mobile clients should really be using xbosh anyway, which avoids these and other issues, but it seems like the bosh/xbosh specs have stalled...) -- Glenn Maynard
