Some of the blame here lies on programmers, not that I'm supporting NTT's approach. I lead a team of app developers for my day job, and one client once sent us some code from a previous development house to troubleshoot.
The thing was polling for new data every 15 seconds. What was particularly surprising was the developer who had written it had quite a good reputation, and was highly though of - on the desktop. And perhaps that's the problem - that people are coming to mobile, writing apps and not considering that what's OK on the desktop is not going to fly on mobile.
(...before someone chimes in here: polling every 15 seconds on a mobile device is unacceptable if you're on a cellular network. Firstly you'll kill the battery, as iOS and Android power down the radios when not transmitting, and secondly you'll eat up bandwidth)
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.
> iOS and Android power down the radios when not transmitting, and secondly you'll eat up bandwidth)
Is that still valid with the apps like gmail@android which use push notifications instead of regular pulls ? For the server to push something, you must be listening somehow
I would love to learn how the device learns the server has a message for it. I tried to find information on it, but I obviously don't know what to search for.
It's less magical than it sounds, but a lot of work goes into it. Depending on the system, hardware can partially wake at fixed intervals to check for incoming traffic, and fully wake to process that traffic.
Notably, most of the stack can stay asleep almost all the time, and wake up only when actual traffic is coming in.
Application-level polling can eat up the power savings as the whole hardware stack must wake up and process an application-level transaction taking anywhere from several tens of milliseconds to several full seconds. Compared to the "napping" state, this eats huge amounts of power.
Comments
Some of the blame here lies on programmers, not that I'm supporting NTT's approach. I lead a team of app developers for my day job, and one client once sent us some code from a previous development house to troubleshoot.
The thing was polling for new data every 15 seconds. What was particularly surprising was the developer who had written it had quite a good reputation, and was highly though of - on the desktop. And perhaps that's the problem - that people are coming to mobile, writing apps and not considering that what's OK on the desktop is not going to fly on mobile.
(...before someone chimes in here: polling every 15 seconds on a mobile device is unacceptable if you're on a cellular network. Firstly you'll kill the battery, as iOS and Android power down the radios when not transmitting, and secondly you'll eat up bandwidth)
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.
> iOS and Android power down the radios when not transmitting, and secondly you'll eat up bandwidth)
Is that still valid with the apps like gmail@android which use push notifications instead of regular pulls ? For the server to push something, you must be listening somehow
Powered down doesn't mean turned off. It powers back up when it knows the server would like to push something.
I would love to learn how the device learns the server has a message for it. I tried to find information on it, but I obviously don't know what to search for.
It's less magical than it sounds, but a lot of work goes into it. Depending on the system, hardware can partially wake at fixed intervals to check for incoming traffic, and fully wake to process that traffic.
Notably, most of the stack can stay asleep almost all the time, and wake up only when actual traffic is coming in.
Application-level polling can eat up the power savings as the whole hardware stack must wake up and process an application-level transaction taking anywhere from several tens of milliseconds to several full seconds. Compared to the "napping" state, this eats huge amounts of power.