On Jul 19, 2011, at 19:42, Glenn Maynard wrote: > On Tue, Jul 19, 2011 at 9:13 PM, Matthew A. Miller > <linuxw...@outer-planes.net> 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".
YMMV My employer has plenty of customers that like to keep the network reigns rather tight. This optional-to-negotiate proposal is one suggestion for dealing with them real-world deployments. > > 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. If a server is sending (in)frequent keepalives, and the client knows it should have them (more) less, then this protocol allows for that to be opted-in on a per-connection basis. It almost seems you're suggesting a service should effectively run a separate connection manager for each variant of device/platform/network/solar activity/phase of moon/etc. That doesn't sound very scalable to me. > > 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. > Sending at the same rate usually means each end will detect a stale connection at roughly the same time. That's a Good Thing™. As Ben stated, it's an optional feature; if you don't want it, don't use it. > (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...) I don't agree with that statement, as others have already indicated reasons for. Also, I'm not sure what you mean by "stalled". XEPs -0124 and -0206 are DRAFT, updated with implementation experience. Are you suggesting we should progress them to FINAL, or do you have a specific set of problems that need immediate attention? - m&m
smime.p7s
Description: S/MIME cryptographic signature
