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)
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.
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
it would be possible for google to create a service/api that does something similar for other apps.
Here's some background:
http://itpro.nikkeibp.co.jp/article/NEWS/20120127/379582/
It's in Japanese, but the Google Translation gives way more info than the TNW and Reuters articles: http://translate.google.com/translate?sl=ja&tl=en&js...)
It also sounds like what they want Google to do is to have app developers route through so that connections pool into a single thread? They don't mention c2dm at all, but seems like forcing c2dm would help (though it would leave Android =<2.1 users in the cold)?
At best, you could wrap the protocols in zlib, but if that actually helped, I'd say NTT's network is already hanging by a thread (and indeed it appears to be). Streaming a five minute video can account for hours, if not days, of polling by email, social media, and other 24/7 background-running clients
There are pros and cons to this approach: some people (me!) appreciate the compression carriers provide, because it saves my bandwidth allowance. But if you had unlimited bandwidth and a fast 3G connection, perhaps you would feel differently.
This is actually the providers' own fault. If you want to keep a connection to a "push service" like gmail, imap, voip or jabber, you usually do so by maintaining an idle TCP connection, where the server can push notifications to you.
However, thanks to the IP address shortage, almost all 3G providers deploy NAT and only give private addresses to their users. That means that their gateways are maintaining connection tracking tables, which usually have a certain timeout after which idle connections are kicked out.
So as a developer, you are forced to regularly send keep-alive messages to prevent getting dropped. And because there is no documentation on the timeout, and it is better to be safe than sorry, most developers go somewhere below 5 minutes.
Not saying this is what happened in DoCoMo's case, but in our experience there are a great percentage of users that do not or cannot use C2DM, and this necessitates a separate connection for each app. There should be a way for the network provider to subsidize a default C2DM connection as it is in their interest.
My guess here is that the software in question is using standard VoIP signaling protocols and not C2DM at all.
Telcos are getting whatever they started. If they wouldn't kill WAP OTA-Push (OMA-WAP-TS-PushOTA-V2_1-20051122-C) 10 years ago, they wouldn't have their network overloaded today, because you would not need long-living TCP connections.
(Similarly, if they wouldn't kill E.164 ENUM, they wouldn't have problems with phone numbers migrating among providers. History is full of examples of telco shortsightness).
For them, it must be hard to no longer own the terminals on their network fully. I suppose they had to start offering Android terminals since their own smartphones were not competitive compared to the Iphone and Android.
But without any control of the terminals' behavior it's very hard to tune and operate a cellular network. It's not so easy to increase capacity, since there's only so much spectrum available for use and the modern wireless technologies can't get much more efficient. Especially in crowded locations like downtown Tokyo the base stations are already about as close as you can have them. It's not something you can just throw money at to solve.
So it's a tough problem. From the handset makers' and app developers' side it's easier to not restrict data usage since they are not the ones paying the price.
As an example, on certain carriers I've worked with, the carrier paid per-request for a network assisted location lookup. Access to the location service was enforced with "secret" IP address and port pairs per allowed application. This "secret" information was compiled into every approved app and was trivially enumerable by brute force or discoverable via decompilation. If I had created a malicious app that used the same port as the carriers' branded navigation software, I could incur trivially incur costs in the $xxx/hour range. Their only recourse would have been to disable that port, and with it, navigation for all their customers (until they could issue an update, which would again be vulnerable to the same attack). They could also kick my phone off the network, but if a worm was every released they'd be screwed.
Mobile networks weren't and still aren't built for general use. Like the internet at large, as time goes on they'll have to improve as false assumptions they've made are accidentally or maliciously violated.
If (relatively) few phones with undesirable behavior can take you down, you're doing it wrong.
