The bandwidth argument is pretty weak, any halfway competent polling will not use significant amounts of data even if done fairly frequently. But a lot of operators pay license fees to the manufacturers of the network equipment based on the channel element usage. And to a first approximation the CE usage will be the same for a phone sends a single packet every 15 seconds as for one downloading at full speed.
I admit with regards to bandwidth I'm often in the minority. Certainly battery life is a huge issue with any kind of polling. Personally, I think it's really important to minimise bandwidth as much as possibly, because you don't necessarily know how your user is paying for it. It would not be unknown for some (foolish?) users to be paying $10+ per megabyte in certain countries/carriers. In the case I mentioned, we were talking about a fairly hefty XML file (which I neglected to mention).
In a cellular network, even just establishing a connection is while use up resources. It's not just about licensing fees. There's a lot of low level control signaling required to keep a terminal connected and in sync, and a base station can only keep so many connected at once. So you really want to connect rarely and then download a lot at once and disconnect again. The more seldom they connect, the more terminals you can support.
Indeed, initializing a session is a heavyweight operation. But something polling every 15 seconds is likely never going to tear down the session. From what I've heard the timeouts tend to be a bit longer than that (e.g. 30s), exactly for that reason.
And yes, there could be physical limits as well causing an individual cell to be fully congested due to open but idle sessions. Either way the polling is causing problems disproportionate to the amount of actual traffic.
In practice, that's basically an oxymoron. Any sort of application-level polling is problematic, and even where necessary, developers almost always take a naïve and highly sub-optimal approach.
Comments
The bandwidth argument is pretty weak, any halfway competent polling will not use significant amounts of data even if done fairly frequently. But a lot of operators pay license fees to the manufacturers of the network equipment based on the channel element usage. And to a first approximation the CE usage will be the same for a phone sends a single packet every 15 seconds as for one downloading at full speed.
I admit with regards to bandwidth I'm often in the minority. Certainly battery life is a huge issue with any kind of polling. Personally, I think it's really important to minimise bandwidth as much as possibly, because you don't necessarily know how your user is paying for it. It would not be unknown for some (foolish?) users to be paying $10+ per megabyte in certain countries/carriers. In the case I mentioned, we were talking about a fairly hefty XML file (which I neglected to mention).
In a cellular network, even just establishing a connection is while use up resources. It's not just about licensing fees. There's a lot of low level control signaling required to keep a terminal connected and in sync, and a base station can only keep so many connected at once. So you really want to connect rarely and then download a lot at once and disconnect again. The more seldom they connect, the more terminals you can support.
Indeed, initializing a session is a heavyweight operation. But something polling every 15 seconds is likely never going to tear down the session. From what I've heard the timeouts tend to be a bit longer than that (e.g. 30s), exactly for that reason.
And yes, there could be physical limits as well causing an individual cell to be fully congested due to open but idle sessions. Either way the polling is causing problems disproportionate to the amount of actual traffic.
> competent polling
In practice, that's basically an oxymoron. Any sort of application-level polling is problematic, and even where necessary, developers almost always take a naïve and highly sub-optimal approach.