On 7/19/11 7:42 PM, Glenn Maynard wrote:
On Tue, Jul 19, 2011 at 9:13 PM, Matthew A. Miller
<[email protected] <mailto:[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-
It makes me chuckle to read you say that this negotiation protocol seems
like an "overcomplication" and then immediately follow that with a
suggestion that folks should be using BOSH. ;-)
Regardless, this is an "optional" feature and if you feel it is too
burdensome for your project, then you're welcome to skip its
implementation, but that doesn't mean it doesn't have technical merits
for the protocol community, at-large.
Cheers,
Ben
