Internet Game Server

[jdart]

Most modern web frameworks have a thread pool. When requests come in, they are handed off to in-memory processor code. After the handoff, the thread is free to service more requests. Each request processor is associated with an application context, including a session and usually a database transaction context. The code may make database calls, but these frequently have minimal I/O because databases do caching and many apps are read-only or read mostly; or if performance is critical the app may use an in-memory store such as Redis for critical data. There is no fork/exec in this kind of system.

With low request rates and few users you can get by with just about any architecture: but this is how you get high performance.

--Jon

[hgm]

OK, I see. So they save time on forking off threads by creating them in advance and just resuming them when there is something to do. And they would not be smart enough to create a number of processes running the CGI script in advance, when they detect there is much demand for it.

I can imagine that is super-fast, but I am wondering at what kind of load you would start to need those techniques. It seems to me that with current CPU speeds launching an 18KB program that is already in memory, and is using perhaps 8KB of data, should also just be a matter of micro-seconds. I would be very much disappointed if I could not satisfy 1000 CGI requests per second that way. And if every user would poll once every 30 sec...

[odomobo]

BTW using CGI, if you set up your server correctly, you can get the basic auth username and password passed through CGI: https://httpd.apache.org/docs/trunk/mod ... _fcgi.html. By default, it appears that the webserver attempts to perform auth for you. You can get the request method from REQUEST_METHOD.

When making an HTTP POST (or anything other than a GET), you can put arbitrary text data as the request body (stdin), so you can format the request parameters however you like.

I highly recommend using these instead of using GET for everything and putting everything in the query string. Of course, GET is fine for anything which does not modify server state (and you can still use basic auth with GET requests).

Not sure how you're making the calls from the javascript side, but these should all be easy to use there as well.

Even if the initial version of the server is a giant hack, as long as its API is sound, we can always replace it later if the need arises.

[hgm]

Thank you for the suggestions. I will certainly study these possibilities. Originally I was considering requiring a different password to be sent on every command (by XORing it with a mask derived from a concatenation of the command parameters and the original password (as seed of a PRNG). Most commands that need identification are unique, an would become invalid after one time use. But the command for posting a game request is always the same, and there is no easy way to force it to be unique without introducing extra server state.

As to your last remark: yest, this is exactly what I had in mind. For now only worry about the required server state and the API to manipulate it, and implement it by the quickest hack available to me, and then later design something more efficient and secure when these caharcteristics start to matter. One efficiency improvement could be to wrap the CGI Game Server in a HTTP server of my own (perhaps on another port), rather running it in a general purpose HTTP server. Then I could also force that all commands that manipulate the game list (creating game requests and starting games) which could cause race conditions) are executed by the same thread. Another thread could be dedicated to polling and submitting moves.

[Ras]

Originally I was considering requiring a different password to be sent on every command

Home-brewn security solutions don't work anyway. From the server part, just slapping https on it with Let's Encrypt is easy and proven. The server config can be verified to be secure via https://www.ssllabs.com/ssltest/ . Even credit card data are transmitted that way. If the client application is not a browser, there have to be libraries to deal with that.

Then you can just send user and password in clear text with every command so that no extra server state is required. On the server, you would only store a salted and maybe also peppered hash of the password, of course. Maybe some sort of continuous command sequence number would be useful along the logic of CECP's ping.

[jdart]

For authentication you can consider JWT, which is a standard for session management (https://en.wikipedia.org/wiki/JSON_Web_Token). User logs in, gets a limited-time token, and then sends the token on each request in the Authorization header.

There are implementations in many languages. See for example https://github.com/pokowaka/jwt-cpp.

--Jon

[chrisw]

I am currently developing a server for playing (human) games over the internet, based on the Jocly user interface. The latter is a JavaScript library for implementing a chess board in 2d or 3d (based on WebGL) display, and enforcing the game rules on it. It already supports a multitude of games, not only chess variants, but also Draughts, Amazons, Annexation, Spline, Scrum, Yohoho, ...

But everything in Jocly is trictly local; it runs in your web browser, and you can do local games with it, but it does not connect to any remote opponent, neither peer-to-peer nor to a server. So that is the functionality I aim to add.

To allow communication between remote users I opted for a Game Server that is embedded in a standard HTTP server, as a CGI 'script'. (In fact it is the executable of a compiled C program.) In such a design the Game Server does not run as a persistent process, handling one command after another. Instead a new process is started for every user (HTTP) request, to handle only that request, and deliver a response to it. The persistent state of the Game Server is completely implemented in the file system of the server machine. The CGI script gives the users read and (highly-restricted) write access to this state.

I try to keep the server side of this design as simple and general as possible. ('Minimalist' would be a good description.) As Jocly is already a very powerful piece of software running in the clients, it makes sense to delegate as many tasks as possible to that. So the Game Server doesn't have to worry about legality testing of game moves, or nicely formatting its output. To it, games are just a list of moves, and moves are blackboxes that it passes along. And data requested by the user are just provided as a number of lines, each a comma-separated list. Clients can convert this info (or the part of it they want to show) into HTML that would display nicely.

Overview of server tasks

The state of the Game Server is basically just the collection of games, where each game has its own state. The latter must be modifiable by the players of that game: they must add moves to it. Of course only the player that is on move must be allowed to add a move, so it must be possible to recognize and verify the identity of the users. For this a (not publicly accessible) password file is needed, storing identities as a (public) user / (secret) password combination. To not unnecessarily burden the server operator, the Game Server must also maintain that password file.

I opted for storing each game in a separate file, recognizable by a unique number. (Like game327.txt.) Each move is stored as a separate line, so submitting a move would just append the move text as a new line to it. The first two lines are reserved for the player names and the game type (e.g. 'brazilian-draughts').

Because users will frequently want to fetch a list of games, and it would be very cumbersome to open all game files to get the player names, the Game Server will also maintain a game-list file (gamelist.txt). In a fixed-size format this contains for each game the name of the white and black player, the game type, the player clocks, and a game-state indicator. The latter is a single character that indiates who is to move (w or b), whether a draw offer is pending (capital W or B), or whether the game is finished (+, = or -). The player names and game type are immutable once the game is created, but the state and clocks must of course be updated on every move. This requires random write access to the file (hence the fixed size of its elements).

List of user requests

* add a user / password combination to the password file
* read the user names in the password file
* read the game list (possibly filtered by a player name or game type)
* read a game file (possibly suppressing the moves he is already aware of)
* put a 'game request' (a game with as yet unknown opponent) in the game list
* satisfy a game request to initiate a game
* possibly delete a game request that no one wants to satisfy
* add a move to a game
* resign a game
* offer a draw in a game
* abort a game (?)

A server could also allow chatting between users. This would add extra state, and extra requests to read or modify that state. I haven't thought much about that yet.

Does it work for Othello Reversi, I hunted for an online server with activity or an engine opponent wayback and never found anything

[hgm]

Does it work for Othello Reversi, I hunted for an online server with activity or an engine opponent wayback and never found anything

I think it does, but for some reason it shows up in the list of games under the name 'Annexation', in various board sizes:

http://hgm.nubati.net/jocly/jocly-maste ... =reversi10

To try a local game against the built-in AI, you can try

http://hgm.nubati.net/jocly/jocly-maste ... =reversi10

[chrisw]

Does it work for Othello Reversi, I hunted for an online server with activity or an engine opponent wayback and never found anything

I think it does, but for some reason it shows up in the list of games under the name 'Annexation', in various board sizes:

http://hgm.nubati.net/jocly/jocly-maste ... =reversi10

To try a local game against the built-in AI, you can try

http://hgm.nubati.net/jocly/jocly-maste ... =reversi10

okay, thanks, they both seem good launched on a PC, when I tried with an ipad browser later, the 3D is not. I know ipad is an unlikely target, but that could be fixed by 2D/3D set to 2D at start (its the other way round right now).

Anyway, the PC version 8x8 defeated me in easy mode, first I thought it was playing dumb, but then .... I was the dumb one.

the communication with a second engine is/will be via a file on HD?

[hgm]

The local version is just one of the examples that comes with the Jocly source distribution from Github. I dont think it supports a second engine, and I never managed to have the Save and Load buttons do anything. (For the latter that might just have been because I had nothing to load.) I also had the experience that the Jocly demo did not work properly on a Samsung tablet: the 3d board image was jumping around like crazy (if you could get it in view at all), in a way that seemed coupled to the orientation of the tablet. (Which could be intentional, but is a very bad idea.)

There is a related project on Github called Joclyboard. I haven't really looked at that, but it seems aimed at making a general game GUI using the Jocly interface through node.js rather than a browser. One of the 'issues' I happened to get a Google hit on mentioned an omission in its support of CECP, so I suppose it does allow connection of external engines.

The browser applet seems to remember its settings in the browser's 'local storage'; So if you switched it to 2d once, it should always start in 2d mode from then on. I don't think the initial startup can be controlled through a GET argument, like the initial game can.