There were plenty of wireless-optimized TCP replacements proposed back in the days when WAP and XHTML Mobile were the hottest things around, but none took root as operators, web servers and browsers needed to adopt them in tandem.<p>Now that smartphone apps are widespread and someone developing a service can control both sides of the connection, there's definitely room for someone to devise a really good TCP replacement (layered on top of UDP) with an iOS library, an Android library, and an Apache mod.
The problem for those of us on capped and/or expensive-per-kbyte mobile connections (in the UK that is everyone who doesn't spend a large chunk on their monthly contract - people on Virgin pay-as-you-go pat £3 for a day's access but IIRC you get cut off after 25Mbytes in that day) with restarting connections early is that the ~20 seconds worth of packets queued up during the blip is going to be sent anyway even though they are now no longer needed. 20 seconds worth of discarded packets could be quite a bit if you were transferring data at decent 3G+ speeds just before the blip.
This is exactly what CouchDB, and Mobile Couchbase for Android and iOS, is designed to fix.<p>Networks are slow. Mobile networks are slower. The most robust fix to the problem is to "optimistically replicate" your application data to the end user's device, so that the network latency does not become part of the user experience.<p>This is a strong fit for applications like CRM or geographically constrained apps, as the data sets are small enough to fit completely on your devices. For larger data sets the issue becomes: which subset of the data should be copied to the device ahead of time.<p>The user should never needs to wait on the network. All data operations are played against the local Couch, which handles asynchronously transmitting changes to and from the remote server, in the background. This pattern makes it much easier for app developers to make responsive applications, where users are never left waiting on multi-second round trip times.
Here's animation of the packets of a Facebook page hit over 3G on a moving bus:
<a href="http://vimeo.com/17248120" rel="nofollow">http://vimeo.com/17248120</a>
Very interesting and sheds some light on the weird latency issues I see here in Rwanda, where 3G issues aren't limited to being on moving trains. Sometimes pinging shows crazy return times of 30000-60000ms. Other times they're only 200-400ms but every other ping packet times out, i.e. one packet through, next one drops, and so on. Still trying to figure out exactly what's happening then.
I'm in a start up that's developed techniques using UDP to allow someone to roam across wifi - in other words we have managed to reduce the tcp delays and time outs to provide consistent and reliable handoffs between wifi zones and devices - regardless what of the network provider. The technology also allows hot handover between femto and wifi too. Right now we're mostly focused on a mobile app to improve broadband delivery of content to mobile users in shopping malls, commercial zones, etc. but that's low hanging fruit. Eventually we believe that this can be integrated in mobile apps to let others us this for true mobility while running broadband services.
The much worse problem is DNS. For big networks that pushes always the same two IPs (even without round-robin) it is a disaster. There are lags of servers, lags of network, dropped packets, useless overhead with EDNS and different packet sizes (timeouts and retransmitions) and above all, the practice by content providers and CDNs to use hundreds of changing in real time hostnames to implement load balancing and/or geoIP based assets loading. They use near zero TTLs which makes caching useless and dynamic sets.<p>Indian Airtel's network is a live example of that disaster. It is almost unusable, while they still actively promoting 3G and iPhones. ^_^
Interesting, suggests a quick fix might be for the client to not use keepalive, or to selectively close connections that are very slow so as to start new ones. Potentially a much easier solution than writing a new transport.
Interesting. I cannot stop thinking how cool it would be if Google actually decides to step in and propose an alternative protocol for mobile networks. If they put it in Android, they already have a huge base for adoption.<p>Ended up writing a piece on Google because of this on my blog:
<a href="http://micheljansen.org/blog/entry/1060" rel="nofollow">http://micheljansen.org/blog/entry/1060</a><p>(shameless plug :P)
As an historical note, most of these concerns are the same expressed in RFC 3481 (category: BCP). You'll note from there that some of the issues are still open even if almost a decade has passed.
Would Vint Cerf's recent work on a high-latency network standard for space[0] apply? Would it make mobile more useful? It's designed for latencies of days (not seconds), so it might be overkill. But something to masticate upon...<p>0. <a href="http://www.technologyreview.com/communications/21601/?a=f" rel="nofollow">http://www.technologyreview.com/communications/21601/?a=f</a>
This is partly why I'm so interested in publishing information at the DNS level (i.e. .tel) - you get to use UDP (or TCP failover), plus other awesome benefits. You can do other innovative things with DNS too.
Is there any way round this for HTML5 apps? I know you can save an app icon on iphone but when you launch it just launches safari which seems to make a network request to check if the site is up to date? (Sorry, I'm a bit naive about all this HTML5 stuff.) e.g. Gmail in safari on iphone is useless when you get long latency situations like this. Is there a way round that?