UGSArchitecture

    Keywords: Online Go

Architecture of Ultimate Go Server

The basic idea is to have an open network where anybody is allowed to put his own server, as long as it uses the open protocol(s)? we define.

At first, this open aproach might seem to cause many problems: 1.people could set up cheating servers 2.the community will be split up into even more pieces

But, taking a closer look, they aren't really problems: ad 1. there will be a central "web of trust" consisting of servers we approved. In general, you don't have to play on a server you don't know. ad 2. right, there are many different servers, but they're compatible to each other and they will communicate in a way that each one may play with anybody.

Of course, the network shouldn't exist of just game-servers. For example, we'll need some rating-servers that store the results and calculate ranks for their users.

Jabber

[ext] Jabber/XMPP is a standard open-source instant-messaging communication protocol, which is mainly used for chat as a free alternative for ICQ etc. UGS will completely base on Jabber, and here's a list of its pros:

  • Jabber wasn't designed just for chat, but actually to cover all real-time communication one can imagine. So, besides text, you can transfer any XML-formatted data with it - for example move coordinates
  • Jabber does all low-level-work like connections, security etc.
  • There are many existing standard-definitions how certain types of communication are done, for example how chatrooms are used. Many of these definitions can be reused and expanded to fit exactly to our needs.
  • There are many free OpenSource Libraries for nearly all programing languages to access the jabber network.
  • Communication is over a tcp xml stream
  • As Jabber is XML a http proxy can be used to connect to server, firewalls wont be a problem!

Communication with Jabber looks like this: client1<->server1<->server2<->client2 sample:

 edrin@jabber.org/work<->jabber.org<->amessage.de<->mawis@amessage.de/home

if edrin sends a message to mawis it will look in xml like this:

<message from='edrin@jabber.org/work' to='mawis@amessage.de/home' type='chat'><body>hello world</body></message>

For further explanation on how Jabber might be used to fit UGS, have a look at [ext] Mikea's draft


Volity

As we've seen above, the Jabber network and protocols already do a great job to support UGS. The [ext] volity-project could even save more work for us, as will become a highly flexible gaming network (of course using Jabber) to support all kind of turn-based games.

Note that it's not decided yet whether to

  • join volity and help to add functionality we need
  • mirror and expand volity alone
  • something inbetween
  • just ignore it and start from the ground

A typical volity-network consists of a number of gameservers and one single bookkeeper that stores all of the results and calculates ratings.

For further information about the volity-architecture, please read [ext] http://www.volity.org/docs/book/overview.html

In general, volity seems a perfect system for just playing and chatting, including many neat features, for example client-independant game-ui-descriptions or a reputation system to deal with bad-behaving servers or users. In order to deal with commentaries, goproblems and other stuff, we'll have to expand it for sure. Because of this, we should talk with them and find out how much they like to get into the same direction.


Discussion

Malweth: This seems like a good way to get going quickly! I haven't looked in depth at the Volity pages, but it certainly sounds similar to the architecture Option 1 above ;) fyi, sounds like they came up with this from the same model: I based the Option 1 architecture on an H.323 type system (Gatekeeper, gateway, client).

I'll look at the Volity pages in more depth. A few questions I hope to answer:

  • Do they run a single project, or is there a different Volity server for each game type?
  • Would it be possible to connect into their servers?
  • Would it be possible to have our own Bookkeeper and still connect in some way to their Jabber servers (if not for games, at least for chat --- a good way to govangelize?).
  • Is there an example of this?

Assuming everything looks good on their site, I'm voting for this ;)

Evan:

  • You can choose to use the main volity bookeeper (the master server) or set up your own, we would most certainly need and want to set up our own. In the future they'll looking to support mirrored bookeeper servers too.
  • We could connect to their jabber servers but we would need to get them to install a module for the servers to understand how to deal with a go game :)

Unfortunately I do feel volity may be superfluous to our needs. It support the communication of graphical information through SVG, which being XML based can be transfered through the jabber protocol. Obviously we don't need this as sending coordinates is enough to play go! It also uses some specialised extension to XML rather than the usual xmpp that jabber uses, which some of the jabber developers seem to be slighly annoyed at.

Malweth: It does seem like it would be a good place to put a go server, but it doesn't seem in-line with our project. Essentially, it seems as though we want to mirror their project with a number of our own customizations (and obviously Go-based). In fact, after our project is mostly completed, it may not be hard to support more than just Go (with their own servers, of course) or adapt to other games.

In any case, there are a number of pros and cons to using this type of system. My biggest problem with it is the current lack of interbookkeeper connections, which would be necessary to support games with a large amount of customization (including a ranking system). The Volity project also seems to be in the infantile stages, which is very far beyond this project but doesn't give us a good picture of its future.


This is a copy of the living page "UGSArchitecture" at Sensei's Library.
(OC) 2014 the Authors, published under the OpenContent License V1.0.
[Welcome to Sensei's Library!]
StartingPoints
ReferenceSection
About