Internet Game Server

[hgm]

I have been contemplating all the advice I got here. As to the (ab)use of the GET method: It turns out the CGI server I made already supports the POST method as well! (I derived it from some public domain basic CGI example I found somewhere on the web.) Provided the arguments are supplied in the body of the POST in the same format as they would appear in the URL of a GET request. So this can be fixed purely in the client, by replacing the AJAX call I was using:

Code: Select all

function a_get_url(channel, url, argString)
{
    channel.open("GET", url + '?' + argString + '&t=' + date.getTime(), true); // asynchronous request
    channel.send('');
}

by

Code: Select all

function a_get_url(channel, url, argString)
{
    channel.open("POST", url, true); // asynchronous request
    channel.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
    channel.send(argString);
}

(The Content-type stuff is needed to make the CGI server accept the request.)

I suppose I could use that same 'setRequestHeader' function to put an Authentication field with the encoded username:password combination in the HTTP header, as the HTTP Basic Authentication would require. I am not sure how to invoke this on the server side, however. I am not in control of the HTTP server there; this is run by the ISP. It seems that for an access to require authentication it must be in a certain direcctory, which then can be configured by a .htdocs file in it, but I haven't found out how to do that yet. I don't even know what HTTP server they are using, although there of course is a good chance that it will be Apache.

I know there exists an interface called FastCGI, which doesn't require the HTTP server to fork and execute a new CGI process for every CGI request, but starts the service once an for all, and then pipes the requests to it. This has the side effect of serializing all requests. Which is very good for precluding race conditions. But totally incompatible with long polling, as the server would be deaf to new requests while the poll is still not fully processed. But I can of course distribute the Game Server functions over several CGI handlers, and let the client address the one that runs as FastCGI for creation of games and game requests.

The long polling and submission of moves is then probably best handled by a dedicated server, not handled by the general-purpose HTTP server, but handling its own TCP/IP connections on a different port of the same machine. For simplicity on the client side it could use HTTP as well (meaning it has to decode the HTTP headers itself, and slam such headers on the response). It can be single-threaded, keeping a list of pollers (and associated timeouts) for each game, and notify all those pollers when the next move for that game is submitted. The polls would time out in the same order as they arrive, so they can simply be put in a circular buffer, with an ALARM call set at the time the next element of the buffer would expire. This would then send a fail message to the poller, (an remove it from the list is was in), if the poll request was not satisfied before, and schedule the next ALARM signal.

The reason general HTTP servers are multi-threaded with a pool of pre-launched threads seems not so much for efficiency / throughput, as well as for fair distribution of this between users: when the requests woul be serialized, everyone would have to wait until an extraorinary slow request (e.g. for a very large file) had finished before they would get their turn. When all requests are serviced in parallel, their processing can always start instantly. For throughput having more threads than you have actual CPUs/HTs will only be detrimental, as it would involve the overhead of time-division multiplexing of the execution, with associated extra context switches / cache flushes. When there is no wild variety in the time required to satisfy the HTTP requests, there is no significant advantage in multi-threading the server.

So the following design seems pretty high-performance: requests for complete games do not need to be handled by a CGI script; they don't even need authentication. These can be handled by the general HTTP server, by directly requesting the desired game files. A dedicated server program could run as FastCGI module in the general HTTP server, and would handle all game creation. It can keep the password file and game list permanently open, and buffered in memory. It can furthermore fork off a second thread, which would run a 'move server', an install itself on another port. This then also would have direct access to the buffered files, and would handle the polling and move submission. The only modification needed in the client would be that it should send the poll and move requests now to another port.

[Daniel Shawul]

A request, if it is not too much work, is to turn it into a server for collecting games to train a neural network just like leela's.
Doesn't need to have all the fancy frontend like leela's. I actually started turning my inhouse game server to be like that
but did not finish it.