How it works

When you are ready for a head-to-head match, you want to find friends with games in common. This is done by the game making Jibe API calls over HTTP(S) to the Jibe Cloud.

1. With a single click you can initiate an instant game challenge that is sent via SIP (over TLS/TCP*) using just the phone number or the user ID of player two.
2. The Jibe Cloud authorizes the invite request.
3. The request is delivered to player two via SIP over TLS/TCP.
4. The Jibe Engine wakes up the game and presents a challenge dialogue to player two to either accept or reject the game challenge from player one.
5. Once the game challenge is accepted, a session is setup, data is exchanged using RTP over UDP.
6. And then when it’s time to text chat, data is exchanged over MSRP, which is designed for mobile, and the traffic is carried over TLS/TCP.

Real time voice and video uses RTP over UDP.

Play Against Your Friends

Typical online gaming services require users to choose a nickname or assign a random ID during sign-up. While this protects the anonymity of the players, it makes it cumbersome to find real-life friends. Users need to exchange these IDs with their friends in order to “connect.” Of course this only works if both are aware of each other using the service. This limits the adoption of the service and slows viral promotion.

Jibe has designed the platform to leverage the users’ address books for discovering which real-life friends are also using the service and added a capability to exchange who has which application. This concept is called “Application Presence.” As soon as a user signs up, the system discovers which other address book contacts are also using Jibe and automatically “connects” users. Once connected, users can send Instant Challenges and track each other’s activity - including which apps their friends have downloaded.

Nickname-based communication, random match-ups and other use cases where anonymity is required are also supported by the platform.

Low latency data

Reducing latency is a critical ingredient in the Jibe platform. We've designed Jibe from the group up thinking about mobile and the next generation of real-time apps. We focus on all the variants of latency: (1) static latency, (2) dynamic latency and (3) protocol-induced latency.

• Static latency reduction: Take out hops and minimize geographic distance through “optimal path routing” on top of a geographically distributed grid of media proxies/relays, which interconnect users across mobile networks. These proxy servers have been strategically located at major hubs and close to the edges of the major mobile networks in order to minimize latency. One could say that Jibe acts like a Content Delivery Network (CDN) only for low-latency gaming.

  This approach alone delivers a latency reduction of up to a few hundred milliseconds when compared to a “centralized” online gaming server (e.g. in the US), which is accessed by users in a different region (e.g. in Europe).

• Dynamic latency reduction: Jibe employs several techniques for minimizing latency arising from congested networks ranging from leveraging WiFi QoS to deep integration with the leading mobile networks.
• Protocol induced latency reduction: The Jibe SDK has been fine tuned for mobile networks and built on top of UDP for the fastest possible transports without unnecessary retransmissions or TCP parameter arbitration. Reliability can be added on top of this where required by the game without sacrificing the underlying network performance.

Just how fast is Jibe's Network?

The key techniques for latency reduction are provided with the use of the Jibe SDK for developers.  Based on global tests we have conducted, we are seeing the following performace benchmarks.

• Game title: Air Hockey (2 players / extremely latency sensitive title)
• Network parameters: packet size ~1KB / 30 packets per second
• Mobile networks: Verizon Wireless, AT&T, Sprint, Vodafone Spain, Vodafone Germany, O2 UK, and Telefonica Spain were part of the trials with participants competing freely with others on a different network.
• Player location: Players were always in the same geographic region/country.

The following table shows typical latency figures from successfully established gaming sessions:

The performance has since been validated with additional game titles from various genres including a high-end car racing simulation, a 3D platform title and casual games leveraging the Jibe network for game data and additionally for live in-game audio and video.

As all mobile users know, there will be situations where the network coverage is too poor or the connection to unstable to sensibly use any application requiring data connectivity – let alone play an online game. So how do you avoid that users try to play each other (either directly or through a random match-up) and end up with a poor experience? The short answer is – "Ping before you play".

Global network

So how does Jibe reduce latency? The first step is to understand where gamers are located geographically so that packets don't bounce around the globe for no good reason. Once you know where two gamers are located we connect them through the Jibe Cloud.

Of course everybody is building games for a global user base – so being able to deliver this improvement to end users requires proxy/game server infrastructure in as many regions as possible – and that is what the Jibe Cloud is all about. Jibe has already been optimized in most major regions including: US (East Coast), US (West Coast), Germany (to serve central Europe), Spain (to serve Western Europe), Japan and Australia with more being added all the time.