152.81.15.4: New distributed turn-based go network - to be discussed (2010-12-13 12:41) [#8176]

Dear go players,

I think it would be useful to set-up a new network (called DiGoNet?) for playing go "by emails", in the vein of OGS (Online Go Server) and DGS (Dragon Go Server). The main difference between DiGoNet? and OGS or DGS is that DiGoNet? would be completely distributed, which means that there is no server at all, but just a set of clients that are interconnected into a network dedicated to playing go.

There are two main advantages of not relying on a central server: 1- There is no cost at all for maintaining the server 2- There is never any downtime of the server: the network will always be alive, never down, as long as there are players using it. At least one drawback though: 3- Hacking and cheating scores might be easier to do - I assume for now we're all honest people.

Please let me know if you think this would be useful, and in case you have experience with go servers, which issues may I have outlooked ?

Thanks for your advices and help,

Christophe

A few details on this idea

How does it work ? Every single player in DiGoNet? must have (1) a DiGoNet? client, and (2) a personal webpage, which contains a complete "image" of the state of the network at a given time. When player A is engaged in a game with player B, A writes down his next move in the client, which automatically update the webpage with this move, and eventually send an email to B. B then "refreshes" his client, which downloads from the webpage of A the new move, and so on.

Player A may also broadcast a challenge (or announce a tournament): his client simply writes this challenge on his own website. This announce shall "slowly" diffuse all over the network thanks to two mechanism:

(1) Every player's client engaged in games automatically updates at every move from his opponents' websites

(2) Every running client furthermore updates from a few random sites every hour

Having no server implies to support some degree of asynchrony between clients: within a single game, the former mechanism reduces this asynchrony to the minimum, while the second mechanism ensures some slower diffusion of challenges and tournaments.

When can it be up and running ?

For now, I have simply written in Java the basic building blocks of the client: the source if available at git@github.com:cerisara/digonet.git

The client can be finished in a few days only, but I need some help to finalize it, and in particular concerning: 1- What is the equation to update the rank of a player from his played games ? 2- Does anyone know how to automatically uploads a file on a personal website in Java ? The client shall support most standard connections protocols to access a website: local files, FTP, SSH, ... ? 3- Same question for sending emails in Java ? 4- Does anyone know open-source SGF editor in Java ? It is not an absolute requirement, but it may be easier for players not to rely on an external SGF editor...

axd: ((no subject)) (2010-12-26 22:44) [#8179]

Love the idea. IMHO large-scale decentralisation - though technically questionable - is the next logical step on the Net (see also SlashDot).

1. personal web page obligation is too heavy - not everybody has access to a web space. but email, yes; therefore an underlying email interface feels better (KISS: keep it simple and stupid, use simple interfaces that last long rather than flashy stuff that are likely to be outdated by next year). (risk: spammers will be looking for that database)
2. maintaining a complete copy of the entire system might be too heavy
3. however, linking up via trusted players ("a la Facebook") could be an option; the client maintains a list of opponent addresses, and allows to select new opponents from the opponents (published?) list of opponents. note that in an ideal case, everybody ends up with everybody's address...
4. a mechanism must be found to confirm that a move has been sent as well as received (to reduce possibility to inject fake moves). Public Key systems might be helpful, I guess
5. same issue for time stamping moves (how do you check that a player did move within allocated time?)
6. score issue: how about following. as each client maintains a database of played games, which includes references to opponents, these can be consulted to confirm each game (each game exists in two databases). problems:
   1. the client database might be altered manually (eg by deleting a game or adding fake games!)
   2. what if user A vanishes away (user A database is no longer accessible, there is no way to confirm the games that still exist in user A's opponent databases)
7. Jago could be used as SGF editor. IMO your software should concentrate on the distribution issue, and let the user manipulate SGF files by a "COTS" SGF editor of his/her choice (despite that fact that assistance in game is another issue...).

See also http://www.dragongoserver.net/forum/read.php?forum=4&thread=29911

willemien: ((no subject)) (2010-12-28 17:18) [#8205]

I was thinking about what you wanted but i think you start at the wrong end of the problem.

What i think what you should do is 1 Think about the way it should work.

- What I would sugest is that you get a number of websites that list players who are in for a game and what settings they want or where you can put your game offer (all similar to the waiting room in Dragon Go server - the websites can be of one player or of more players ect.

2 Write some protocols

- Write detailed what information needs to be exchanged between player - waitingroom and player - player. - Work this out in great detail. (which stages excist, what info needs be send at which stage, what needs to be authenticated ect. (and how) - make a complete interface decription (Which tags you use, how the stages interoperateect, best is to make the commando's information as human readable as possible and to re-use sgf gtp or other go related protocols . )

3 Write some programs that can be freely used and that make this project working.

(and were every player can add its own specific wishes to)

4 maintain a list of websites that offer the waitingrooms. (or think of a way to also do this distributed)

Maybe it is better to move this tread to a subpage of Turn-Based Go Servers (how about Turn-Based Go Servers/ dstributed? ?) where it is easier to respond in others comments. (wnd we can WME it regulairly)