I'm still working on the minimal multiplayer game to be run from the Racket web-server.
I have a few questions in the following big post, most of which is to establish context.
I'm planning to maintain a single copy of game state in the Racket web-server. I don't (at present) plan to place it in permanent long-term storage, because I don't expect any of hese games to last long enough for crash-recovery to be relevant.
The players will be connecting from various machines across the internet, using various browsers, likely versions of firefox, chrome, chromium, edge, and maybe even internet explorer. They will probably be using different operating systems, likely Linux and Windows.
The players will also be using an out-of-band voice communications channel, likely jitsi or discord. At least I don't have to worry about that for now.
This is not a massively multiplayer game. I'll have enough hardware resources even if the server is a very old computer (which it is).
Here are the parallelisms I may need to worry about:
Processes running on completely separate computers, connected by http or https over the wider internet. (i.e., not just a LAN)
OS processes. (I hope I don't have to deal with these in the server. I'm not planning to use CGI scripts.)
OS threads, which may be on different CPU's within one OS process. Doesn't Racket have some way of talking about these?
Racket threads, running within in OS thread.
The form of parallelism involved in the web-server for incoming requests, which is likely one of 3) or 4).
I understand that when requests come in from client machines, they are processes in parallel. Which form of parallelism is this?
My conceptual model is to have the entire web server run in one OS process and to use Racket semaphores for mutual exclusion, thereby separating the incoming requests. So on the server, requests will come in, by serialised by waiting on a single semaphore, update the game state one at a time and respond by sending an appropriate response to the client's browser. I've already implemented cookies to tell players apart.
Are Racket semaphores the right tool for serialising incoming requests? Or are they operating on the wrong level(s) of parallelism?
Do multiple requests from the same browser instance create separate processes (of whatever layer?). If not, will semaphores fail to separate them? (Some semaphore implementations I've encountered won't let a process wait on itself.)