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.
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).