A byproduct of the explosion of mobile apps is a user’s increased expectation for realtime operational tempo, the requirement of data and information to be delivered in as it happens, or as it’s created.
To put it simply, we expect data as it happens. We expect chat messages to arrive the second they’re sent. We expect to see our taxi moving on a map smoothly as it approaches us. We expect sports scores, stock prices, and event coverage to publish as the event takes place. And we expect our messages and data to be there the second we come out of a tunnel.
However, there are a number of factors that we need to consider when building realtime data streaming for mobile apps, very different from its web counterpart. Bandwidth and battery consumption, security, and reconnection and catchup in unreliable environments. These are all tough challenges for a mobile developer who wants to build realtime functionality in their application.
Now take all those challenges and apply them to 7.7 billion mobile devices spread across the globe. That’s right, there are more mobile devices than humans. Just like with the explosive growth of the Internet of Things, connecting that massive mobile ecosystem is an important logistical challenge. Some quick numbers:
- Number of mobile devices on Earth: 7.7 billion
- Mobile data traffic per month: 1.5 exabytes
- Connection speeds: 1387 kbps (up from 526 Kbps in 2012)
- Average smartphone usage per month: 529MB (up from 353MB
So yes, there are a ton of mobile devices, even more mobile apps, we’re using them more, and our connections are getting faster and faster. So, how do we simplify these logistic challenges, and reduce power and bandwidth consumption for such a massive collection of devices?
This is something that global data stream networks are looking to solve today.
Connectivity for a Massive Mobile Apps Ecosystem
Realtime connectivity for devices at its core is about maintaining an persistent open socket connection. An open socket connection is really just a memory path over the Internet. You have lots of in between routers and hardware devices that need to keep memory tables. The initial establishment of the socket holds where each memory packet needs to go, setting its route.
Stationary devices (your computer, local devices, AppleTV, etc) are fairly easy. Connectivity is usually a consistent single IP address endpoint, and establishing, and establishing a TCP socket needs to happen just once. The TCP socket is persistent for extended periods of time with minimal interruption, and if an interruption does occur on that socket, it can easily recover and resend the TCP tuple (think 3-way handshake).
But obviously mobile is not stationary
Realtime connectivity for mobile devices face constantly changing IP addresses. Every time the IP address changes, say from 3G to WiFi, or downgrading from LTE to EDGE, or whatever the connectivity is, the IP address is rerouted and reestablished onto the mobile network. Every time a reconnection is made, small TCP packets are repeatedly sent to essentially say “hey, I’m still here, but I’m on a new data path.” And this is essential for always maintaining an always-on, persistent connection for realtime data streaming and signaling.
So now the biggest challenge. How can we maintain an open socket connection while minimizing battery drain, bandwidth drain, and ensure a reliable connection through switching networks?
Global Data Stream Networks
Global data stream networks sit in the middle to facilitate this conversation, to make sure all the pieces of the mobile connectivity puzzle are available on demand, in realtime. The millisecond data needs to be transferred, or a signal needs to be sent, a data stream network ensures that.
So, how do we do this?
Low bandwidth messaging and no open ports
For realtime publish/subscribe messaging, some developers try polling, where you’re repeatedly asking “is there anything new? Is there anything new? Is there anything new?” Most of the time, the answer is no, and every once in a while, an update is sent. Not only does this keep ports open (a massive security risk), but also requires a large number of servers and bandwidth to run.
Multiplexing data streams is an essential piece of building streamlined and low-consumption data streaming. This enables developers to group data stream channels on one connection, slashing CPU, power, memory and bandwidth consumption. Additionally, by grouping channels, network bandwidth is reduced.
HTTP Keep Alive
Take this analogy. Say every time I wanted to say a sentence, I had to shake your hand, say the sentence, and before you respond, you’d have to shake my hand, then give an answer. After a while we’re going to get tired of this.
With HTTP keep alive, you shake hands once, and that’s it, and you never tear that connection down. Over time all those handshakes drain battery, consume lots of bandwidth, requires a huge amount of data.
Combine multiplexing with HTTP keep alive, and you have a streamlined, single connection out for realtime functionality, without the bandwidth, power, and CPU drain.
Realtime functionality is fuel for mobile. Users are increasingly coming to expect their mobile applications to be realtime. But with those apps comes a number of considerations, including power, CPU, and bandwidth consumption, as well as security and unreliable networking. A reliable, globally scaled data stream network is the best way to connect mobile devices, and will continue to grow the mobile and Internet of Things space.