![]() StartingPoints Referenced by Homepages
|
Designing a Go Server
Keywords: Software
What features does a public Go server need?
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.
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:
Here's how it works. Alice registers with the Database server by sending it her name and a 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. 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 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 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:
yoyoma - Have you looked at
Neil - I have looked at 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. 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. 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 alot, 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. This is a copy of the living page "Designing a Go Server" at Sensei's Library. ![]() |