Home‎ > ‎

Motivation

To understand the motivation behind Hydra, we first examine the traditional server-client architecture.

Traditional Server-client Architecture



This picture illustrates the traditional server-client architecture used in most multiplayer games/applications today. Clients are the players or users who connect to a game server, which runs and maintains the game. The main disadvantage is that having and maintaining a game server incurs cost.

Super-Peer


Some games then allow a client to host the game server as a super-peer. Examples of such games are DoTA and most first-person shooters. Since there isn't a need for a central server, the game developers does not have to incur the maintenance cost. However, one disadvantage is that the game host cannot fail or disconnect, or the game will end abruptly. This is certainly not desirable in any game.

Pure Peer-to-peer



Another approach is possible, whereby we do away with a central game server and have every peer communicate with each other. This is what's known as a peer-to-peer architecture. In this scenario, a client leaving or disconnecting will not adversely affect the game. However, since there is no longer a game server, who will maintain control over the game?

This need for control is important because the messages send between the clients can be lost of delayed. For example, if two players pick up a pot of gold, only first one who picks it should get it. But how do all the clients agree on who is first? With a game server, it can decide based on perhaps which message got to it first. But in a purely distributed peer-to-peer system, different clients might get the messages in different order.

Thus while file sharing or instant messaging can be done peer-to-peer, it is not easy to write games or application that requires distributing logic.

Hydra



This is where Hydra comes in. Hydra employs a super-peer architecture which emulates a traditional server-client architecture which programmers and developers are familiar with. In addition, to overcome the limitations of a normal super-peer architecture, Hydra transparently creates a backup server on another client and keeps it synchronized with the primary server. Thus in the event any of the server were to leave the game or disconnect, the game will be able to continue without any interruption.

In this way, Hydra gives us the advantages of a peer-to-peer architecture without the complexities in programming in pure peer-to-peer.

Comments