Designing a Go Server

    Keywords: Software

What features does a public Go server need?

  • How do people prefer to get a game? Is it better to have game offers sent privately to individuals (as on IGS and NNGS), or to have game offers to go the whole group (as on Yahoo and KGS), or something else entirely?
    • Neil - I prefer the KGS way, personally. I think having the negotiations automated lets people who don't share a language get a game more easily.
    • Evand - I definitely prefer the KGS way.
    • Benjamin - Well, I'd like the KGS way with an additional option to offer matches directly.
    • Slade - I've always wondered why there wasn't a text box in the challenge window where you could type to your opponent. I see this the best of both worlds. Being able to negotiate with your opponent (without switching windows) and having the dialog box to set the options. - Guest The KGS client CGoban 3 offers exactly this feature.
    • Hiker - I'd also like to see a list of opponents who are responding to my match offer. As it is now on KGS, I can only hear that I am receiving more than one challenge. I have to decline an offer in order to see the next in the qeue. I'd prefer to see a list and select from those who are offering a challenge.
    • jfc - I prefer the FICS way; With FICS you can specify a range of parameters and it will automatically pair you with a compatible opponent.

MrShin: You can see all your opponents who challenge you on KGS. Just click the tab next to your opponent's name. This will pull down a list of your opponents and their ranks. Click on the specific name to select them as you current potential opponent. Hiker: Thanks MrShin!

    • Allowing only automatic pairings for ranked games is the only statistically sound method.
  • How should conversation be handled? Is it better to have a few big rooms (as on KGS), lots of size-capped rooms (as on Yahoo), a mixture (as on IGS and NNGS), or what?
    • Neil - I think the big rooms seem nicer until they get too big to manage. wms has spoken of needing to break up the English Room on KGS. I'm inclined to believe him that too-big rooms don't work. Yahoo seems to cap rooms at about 100 users.
    • Evand - I think the important thing is that people be able to create rooms of their own, and that there be accessible game lists that large portions of the server watch / put their games on. A global game list + room specific games as discussed on the KGS wishlist / plans way seems correct to me.
    • Benjamin - I'd also like a separated global list.
    • excession - I'm of the opinion that rooms that are "chat only" and rooms that are "games only" would work. But you'd want to be able to negotiate games in the challenge box as described above.
  • How centralized should the design be? Should all traffic go client-server-client, or should some things to client-client? Should the server keep detailed records of every game and make them available to the public?
    • Neil - Centralized games allow the server to check for possible cheating, but really, how can one cheat much in Go? Perhaps everything but the clocks can be made to go directly from client to client. As for data, A centralized server allows for a large database of games to be stored (as on KGS), but then if people rely on that, the burden on the server's resources will only grow.
      I'm heavily inclined to design a game on top of [ext] Jabber, which would allow for as much decentralization as we wanted.
    • Evand - I am in favor of everything being server-mediated. Remember that one can cheat with multiple accounts in regard to the ratings. Also, client-client communication runs into more problems with firewalls than client-server does. Of course building on top of Jabber helps that.
    • Anon: A note, possibly against client-client, is that some providers blacklist a large portion of some asian networks who have at one point been suspected as spammers. In a client-client system, every individual client network will have to be permitted to talk to the other network.
    • Anon: Another note, that client-client systems provides each player with the other's IP. It would then be possible to launch a DoS attack on your opponent, slowing down their computer so that they run out of time.
    • Neil: True, however, if we go "client-to-client" via [ext] Jabber, then the user's network details will be hidden. Only their Jabber ID (Think email address) remains visible.
  • To what outside rank system, if any, should a server's ranks be anchored (if any)?
    • Neil - Not being affiliated with any go associations, I have no opinion here.
    • Evand - I doubt it really matters. It might make more sense to tie it to some other server rather than an association, even.

What other thoughts to people have on the design of a Go server from scratch?

Evand: I'm interested in seeing this happen. I'm not really happy with any of the go servers so far (I think KGS is my favorite at present, mostly for the features available). I'm afraid I don't really have time to help with the effort at present, as life is busy and I have other programming projects. Good luck to those interested, I hope to see you there once it's up :)

Neil - Another issue that would need to be addressed is the balance of power: It is necessary to give power to trusted individuals so that problems can be solved, but it is necessary to limit that power to prevent problems from being caused. Unchecked administrative powers can turn any environment hostile, like a bad IRC? channel. Weak administrators can turn any environment hostile, like a bad Usenet newsgroup?.

PatrickB - Re: centralization. I've contemplated how to split and distribute the functionality of a go server at times. In my view, most servers do at least three moderately separate things.

  1. They provide a semi-trusted place to play games and guarantee that the games played at that location were played by certain rules and standards
  2. They provide a rank based on results - currently these results always come from the same server that issues the rank.
  3. They provide a way to meet other players and to chat, to review games, etc.

The first two of which people generally regard as "basic functionality", and the last one is each server's "added value".

I think it shouldn't be hard to standardize the first two and completely decentralize their management. In particular, I envision separate game and rank services that (digitally) certify results and ranks that they supervise and compute. For example, each player register a public/private key pair for their identity, and then after they play a game with someone, both players (and the server, if they use one) sign the record and result. Similarly, a rank server would take certified game results (probably directly from one or more servers to avoid cherry picking of good results by players) and produced digitally signed rank certificates that, for example, included expiration dates.

A gaming infrastructure like this could essentially be independent of a go server. Game servers and/or players could decide which other rank authorities to trust and which other game servers and rank authorities to accept ranks/results from. By splitting functionality like this, there's also nothing that prevents someone that thinks that a server's ranking system is horrible from writing their own and deploying it independently. You'd have to have some way of quering a game service for *all* of the games played by a particular ID so that users couldn't just cherry pick their good results, but this shouldn't be hard... In fact, such a service could even accept signed results from a wide range of servers, instead of results from just one server.

Anyway, just something I've contemplated before that I thought I'd share as long as we're brianstorming this sort of thing. And of course, someone else may have thought of this and indeed already done it - if they have, let me know because I'd like to take a look at it.. :)

Neil - Interesting analysis. This will take some time to digest, though, as it's challenging some hidden assumptions I had.

Evand - Actually, I had been thinking some things along the lines of what Patrick suggested, but not so clearly formed. I like the general idea, but I was thinking about it in a more peer-based manner. Specifically, how to do a reasonable ranking system without a server. Each player would collect game records for themselves, and sign the result when done. They could also sign the start of the game and potentially along the way. Then, when you went to play someone, you could ask for their complete collection. They would give it to you, and you could see their history, results, unfinished games, etc. If they don't give you the whole thing, then you would discover it when you played someone who they had also played -- that third party would give you a new game record for someone you had already played, which would demonstrate that they had held something back from you. By dating games and signing everything you could make it rather hard to get away with cheating. At that point, every person can collect game results and compute their own rankings. Servers then act as rank servers and game collectors and chat rooms, and there is no particular need to play mainly on one server. Anyway, it seems to me that you could build a remarkably decentralized ranking system. The only trouble I see is with times, though it might even be possible to prevent time cheating without a trusted server involved. Time to go reread Applied Cryptography...

Neil - I think that under this sort of design we can split up the game environment into four parts:

  • Database Server
  • Time Server
  • Match Server
  • Rating Server

Here's how it works. Alice registers with the Database server by sending it her name and a [ext] GnuPG public key. Bob does the same. Later, if Alice and Bob want to play a game (never mind now how they decided to, or how they negotiated the terms), each sends the Database Server a signed intent to play (including their name, opponent's name, expiration date for the intent, and a time when the game is expected to be finished). When both players send in a matching intent, the Database Server tells them they may begin. When the game is over, each player sends the Database Server a signed record. If the records match, the game is recorded and it's over. Dispute resolution can be handled as the Database Server admins choose.

How is the game played? An untimed game goes client-to-client, with a subscription protocol that allows permitted viewers to ask for the current game state and to be notified when new plays happen.

A timed game does require a third party: a Time Server. After being told by the Database Server to begin playing, Alice and Bob choose a Time Server recommended by the Database Server and tell it the timing structure of the game. They then send the moves they make to the time server in addition to going client-to-client. Sending the move to the server works exactly like hitting a clock. Whenever the clock is hit, the server sends a signed message to each player of the move and the time left for each player. When the game is over, the Database Server can be sent this log along with the record to help prove its authenticity.

What good is the Database Server? Easy, a Rating Server use them to determine rating. The server can gather information from wherever it wants (national association rating, multiple Database Servers, however it wants weighted however it wants) to determine a rating.

How is the Rating Server used? Match Servers, where people gather to socialize and negotiate game offers, rely upon them to help users choose the right opponent and handicap.

In practice, the Rating, Match, and Database Servers would probably be concentrated together. Trusted Time Servers are good to have spread worldwide, though, to minimize network latency problems.

With good cryptography spread throughout, this could work.


PatrickB: Interesting ideas, Neil. In general, my thought is that defining standards for signed games and ranks should be separate, lower-level standards that could be used to build what you discuss. Then, for example, KGS, IGS, the AGA, and others could start using that to share results and to make ranks portable without mandating the different roles involved in creating/running games, aquiring a list of games from a specific person, or managing time, even though, of course, all of these things are necessary for an actual server. I was actually trying to stay away from the specific design of how games are generated, for example, to avoid tying the hands of existing servers and organizations, and to keep each layer of the design as simple and independent of the others as possible.

Neil: It sounds to me like the layer you want to standardize is what I would be calling the Database Server interface. If the AGA decides that it trusts KGS and wants to use KGS games in its ratings calculations, the AGA would be acting as the Rating Server and KGS would be acting as the Database Server.
Oh, I feel like I'm getting close to pie-in-the-sky talk here. I need code, but there's so much that would need to be done just to get a prototype of one aspect of this, and I'm not even sure if this design has holes yet (example: the issue of Alice's hard disk crashing while in a game with Bob, leaving Alice needing a way of trusting Bob's copy of the game in progress, seems doable but difficult).
This is where just writing an NNGS client would help. At least then I'd have something upon which to build and test the new game protocol.

PatrickB: Well, my point is that there's a difference between a standardized data format (e.g., signed SGF files and "rank" statements) and the actual API or protocol for talking to, for example, what you call a database server. We can define a data standard that would be immediately useful for any server author without having to mandate how the data is handed around or tackling the harder problem of designing the servers or protocols that share the signed data. In fact, designing such a data format standard given that we already have a good standard for games (SGF) is probably very easy to do. Of course, we may already be in violent agreement here, and I'm missing that fact. :)

Neil: Yes, we agree. I thought it was a given that we'd be using [ext] GnuPG/OpenPGP-signed SGF records for the transfers, since I'd already mentioned GnuPG earlier. It seems to me that we should be able to tack on an armored signature at the end of an SGF record, after the close of the last node.

PatrickB: Yes, something like that. It might be worth considering embedding the signature as an attribute in the game record itself so that it's directly readable by an SGF reader without removing the signature. The problem with this, of course, is that you'd have to standardize how to remove the signature attribute from the record so that you could actually check the signature, and that might make this more hassle than it's worth.

Neil: OK, better idea for the Signed SGF? format: We can rip off the file format that [ext] KOffice and [ext] OpenOffice use, which is a compressed archive whose mime-type is distinguishable on inspection. The archive would contain a tag file that marks the file as Signed SGF?, an SGF, then the signature of that SGF.

w00t: I don't think, that client-client Game Management can work well... It's important that the server got the full control and that the clients are clients! The problems you are talking about aren't existing then. Both clients send their moves to the server, and the server manages time thingys and so on..

PatrickB: Neil: I don't see how adapting the KOffice format is particularly useful. It'll mean that the signed SGF files couldn't necessarily be read out of the box by normal SGF editors, and that the format will also be relatively complicated. It has neither of the advantages of our previous two proposals.

Woot: The signed SGF stuff we're describing isn't particular to a server architecure or how games are arranged. It's in fact independent of whether games are played on a server or directly between clients.

Neil: w00t: The reason it's safe to pass work off to clients in Go is that Go is a game of perfect information. It's easy to see if something's gone amiss.

PatrickB: You do set a high standard for this. I don't think it's possible to get what we want with SGF version 4. Maybe a signature extension needs added in a version 5?

PatrickB: So, I see two possibilities:

  1. If SGF editors ignore text before and after the actual nodes in the file, then we should use simple GPG signing of SGF files gets us what we need without doing anything extra or breaking the standard. I'd prefer this solution, but a quick glance at the SGF standard doesn't show this is as part of the SGF standard at least...
  2. Assuming they do _not_, how about a new game property (perhaps SN?) the includes the ASCII-armored digital signature for the game. This signature covers the contents of the SGF file before the addition of the SN property; to verify the signature, remove the SN property from the file and check the hash of the resulting file with the SN property removed. A simple UNIX sed script should be sufficient to do this using temporary files, for example.
  3. Scryer: a third possibility: Use an existing SGF field to hold the detached GPG signature. For example, C[], the generic comment, or SU[] (setup), which I don't see used much and which also accepts simpletext.
  4. Darron Shaffer: Fourth: Add a new property for signature. Define CAREFULLY what portions of a sgf file are signed over. There is a lot of room for discussion here. Does adding comments invalidate a signature? How about variations, if the main line of play does not change? Annotations? Whitespace changes should almost certainly be ignored (especially line endings). Ideas can be taken from the XML signing standards which have similar problems.

yoyoma - Have you looked at [ext] GGS? It might generate some ideas for you. Personally I think it would be cool to have a server with a lot of different games. There are some out there, but they either have sucky UI or not many players.

Neil - I have looked at [ext] GGZ and I have just now looked at GGS. I think the only point in using them is to take advantage of the features they have already implemented, but some of it is really no good for our purposes. Consider ratings. Both GGS and GGZ force and Elo-like rating.
So, to me it makes more sense to base the design on something like Jabber, where we know it will always be good for us because it implements nothing that's game-specific.


BobMcGuigan: I don't want to rain on anyone's parade but I don't really see the need for another go server. Granted every server now up has its strong and weak points but nothing seems bad enough that we must have yet another server. On the other hand, reading this duscussion is very informative concerning just how much work it is to set up any reasonably functional go server.

Neil: Well there isn't really any need for a new server, no. There really isn't any need for the game of Go at all, either. There are people can derive pleasure from both, though.


Neil: As for the game playing wire protocol, we can do something based on SGF, GTP, KGSueMe (why not learn from KGS? :-), IGS, or something entirely new.

I need a development opening here, and writing a simple game player would be a fine one. So I hope that someone here has some experience to share on the client side about what protocols are good or bad.

Peter: Speaking as client programmer about protocols, I would prefer an open protocol like IGS, open in the meaning of human readable and not a binary protocol like KGS, but base it on XML or some other well formatted specification. Though XML sounds fine. I see no advantage of using a binary protocol, it only makes command processing more difficult, and there are good XML parser libraries available. The IGS protocol is okay and well organized, but quite outdated as it was written 1990 with telnet in mind so the output itself can be used for playing. This makes command parsing unnecassary complex and can be avoided using XML or something similar.

About client-client communication for playing: Forget it, in my opinion. This leaves too many possibilities for cheaters. The majority of players is honest, but the small fraction of cheaters can make ones life miserable. Also forget the idea of a "trusted client". Software which is on the users machine can be broken. Only what is on the server can be trusted. Even if you encrypt the stuff, some decryption key must be bundled in the client software, and this makes it possible to break.

Neil I agree. I'd never trust the client. If I do client-to-client playing, the protocol will be such that the player doesn't have to trust the opponent. He'd only have to trust GnuPG's math.

rfielding? i have read some of wms thoughts on opening up the protocol and allowing new clients as a result. imagine that you keep losing to some guy that has hooked up a fuseki/joseki/shape engine into his client, is playing out possibilities on the board during rated games, or is easily able to trick 2 stronger players into playing each other through him. part of kgs success seems to come from the fact that all kinds of barbarism is kept in check by forcing everyone to use the same client. if you open up the protocol, then you open up a free-for-all on client implementations. kgs would never be the same after that.

w00t: I'm exactly of Peters oppinion... and I don't see any real advantages of client-client playing. Furthermore I agree with the protocol design.. KGS protocol is bad in my oppinion! A text-based protocol with full documentation would be much better.

What's also important, is that the server and the standard client is open source.. (ok because i would enjoy helping in developement.. and to develope my own client..) but on the other hand it would be kind of strange if everybody sets up his own server.. Perhaps something like a network would be a solution (similar to IRC)..

I think I didn't really get what you wanted with signed SGFs but if it's about the rating of players... I would prefer the server calculating ranks out of game results played on the server itself.

Neil: The point of signed SGFs is to allow servers to calculate rank from a broader sample of games than just those played locally, and be able to trust those results because they're signed by a server key the rank admin decided to trust. In the case of a network of servers (like email or Jabber, which is a network I'm considering using as a transport for the whole game framework) this sharing is especially important.

As for cheating, I still don't see how one can cheat in a perfect-information game.


starline: If your going to create a new server, why not fill a niche that has not been filled yet. I have been thinking for a while that it would be nice to have a real-time go server that promotes 'mini-go' (9*9 and 13*13). Especially it would be neat if players are given separate ratings for these 2 board sizes. IMHO this is the way to make it big time in the go server business ^^

Neil: Well, with everything so decentralized as described above, it'd be possible to do all kinds of ratings: 9x9, 13x13, 38x38, Pairs, you name it. I also think that having independent, unregulated chatting would be a useful niche to fill.

starline: Think about it. Why was KGS such a big success? I would say for 2 main reasons a: originality, b: quality. By originality I especially mean that KGS was doing things that were not being done elsewhere. Same goes for DGS. Honestly, I don't know about this 'decentralised' thing, but I feel you are trying to do too much. You will end up maybe learning a lot, but probably not creating a successful go server (if you even have the time/motivation to get one of the ground). If you keep it simple and focus on one niche area which has not been covered (i.e. mini-go) then I feel you have the potential for a very successful and original go server. Partly I'm saying that there are already very good (conventional, i.e. 19*19) go servers out there, but also, why would one throw away an oportunity to create something special/unique which will be also be serving the go community and giving a higher profile to a valid and interesting area of go (not to mention its importance for teaching beginners).

starline O.k. I see that you have reasons for wanting to create a new server (i.e. unregulated chat). Probably you won't be interested in my mini-go idea, but maybe someone else will..

Neil: My hope on this page is to create a framework that lets people create servers to satisfy their own wants. With such a framework established, inserting your 9x9 rating server and 9x9 chat server would be easy. Decoupling chat from centralized authority is just one practical example of how I think this kind of community of servers could attract users today.

Bob McGuigan: As far as I know, no existing go server allows timed games structured the way they are in the Japanese fast game TV tournaments. The timing system used has some desirable features and seems eminently usable in server go. Specifically, each player has a fixed amount of "thinking time", say 10 minutes, for example, and after that each move must be made in 30 seconds. The unique feature is that as long as a player makes his move within 30 seconds of the previous move no "thinking time" is used up. If you use more than 30 seconds on a move it costs you one minute of thinking time and you have the remaining 30 seconds of that minute before anouther minute is charged. Thus you can preserve your thinking time until later parts of the game if you want to. This way if someone plays rapidly through the opening it might be possible to spend five minutes on a life-and-death situation in the middle game.


Benjamin: Did you look at the Ultimate Go Server-project I've started (when I forgot about your page, actually...)? Maybe we can work together. How far is your project right now?


erislover Multi-color go, e.g. three color go or four color go, would be something that could be handled by computers quite well. I have always enjoyed [ext] Chess 4 and I think go could have this multi-player quality as well.


Designing a Go Server last edited by 50.23.115.116 on January 27, 2015 - 05:21
RecentChanges · StartingPoints · About
Edit page ·Search · Related · Page info · Latest diff
[Welcome to Sensei's Library!]
RecentChanges
StartingPoints
About
RandomPage
Search position
Page history
Latest page diff
Partner sites:
Go Teaching Ladder
Goproblems.com
Login / Prefs
Tools
Sensei's Library