One of the challenges of building an enterprise-class software platform in the cloud is making it reliable and high-performing over all types of wifi and cellular networks. We spent a lot of time testing multiplayer TraceWord games on various crowded public wifi networks and on 3G and 4G networks across multiple service providers and signal strengths.
You would think that as long as you can connect to the Internet through any wireless network, everything should just work, but there are actually many ways in which both wifi and cellular networks can misbehave, from dropping data packets, to timing out after a certain period of time, to constantly dropping and re-establishing connections. None of these situations are good for maintaining any sort of real-time activity, and the server system fielding and processing connections from mobile devices must be able to handle them. Each time we tested the game over a new network configuration, we got a slightly different result and had to tune the server accordingly.
There was one network we hadn’t tried yet, though. I just took a trip this past weekend, and they offered an in-flight wifi service for the passengers. I signed up and got my pass code, and once we got above 10,000 feet, I was able to log in. My son was excited because he figured he’d get to watch Netflix, even though I told him not to get his hopes up. Sure enough, the connection was too weak and intermittent to maintain a video stream, even streams from YouTube. I could check my email, but latency was long, and a couple of times it was unable to make the connection to my mail server at all and I had to keep retrying until it got through. Granted, the plane was crowded, about 175 people, and I’m sure there must have been at least 20 to 30 people using the service, maybe more.
The service is likely designed to provide basic connectivity for email and static web browsing, and it was clear we could not expect to experience any rich media along the way. Naturally, I got curious about how the Native Cloud Software Engine would perform under these conditions, so I opened Skype, and after several minutes of long waits while Skype worked to exchange a few short messages with Shannon (our founder/CTO), we agreed to get a game going. I created a 2-player game, thinking that if Skype was even having this much trouble, there was a good chance we wouldn’t be able to get through a game.
Shannon joined the game and it started immediately. I found the first word, and the system acknowledged it quickly, and just as that happened, Shannon’s first word appeared selected on the board. The battle had started, and the words were disappearing quickly. The game’s responsiveness was impressive, with no apparent latency whatsoever! It was all over in just under two minutes, no dropped players, no long pauses, no problems at all! Plus I won, but it was neck-in-neck all the way!
So even at 30,000 feet, I discovered, our software engine really performed, and it’s a testament to the way our servers communicate with devices and process data communications. Because we have deployed our own system layer in the cloud (Native Cloud OS) and we communicate with it using our own programming language (Native Cloud Language), we are able to provide a much leaner data communications channel than conventional systems. This high level of communications reliability and performance is one of the main reasons we are able to call our technology Native to the cloud, and one of the many features of the Native Cloud Software Engine that make it such a disruptive player in the cloud programming platform space for game developers and enterprises alike.
Native Cloud Systems 