As I get deeper into the technical stuff around connecting players and redirecting them between servers, i've needed to come to some decisions around terminology. So that I can define some tables and hopefully not have to rename them in the future.
First up to define is that thing with a CPU and a network adapter that runs Linux. It could be a VM or a physical computer, or even EC2 or a Docker container etc.
I'm thinking machine as the term, is the M in VM. Host is pretty good as well, it leans more network connected but maybe a bit ambiguous about the underlying resources. Where machine feels more specific about a thing with CPU and RAM and disk space. Also in my mind having many machines feels nicer than having many hosts.
Server: A valid term, the problem is it's generally valid for so many things, so best to avoid adding another meaning to it. I'll try to only use "server" in a "client/server" sense at the code level.
Rig: While a silly idea, maybe a little less silly in a game dev context. Tho I think most would think this refers to the end users machine, not the machine in the cloud hosting the game.
Box: Too generic I think, and gives the indication that it is a real physical box somewhere, which is a little different from a VM.
The running server code. There might be many of these running on a server, they might all be the exact same code or different versions or totally different games or services entirely. They also have multiple threads to split work up.
Process mainly wins by default, as everything else has drawbacks in one way or another. Maybe the only weird thing is a process will have a processId in our database, but also a pid of the running linux process on the machine.
Server: See this works everywhere so it's a bad idea ;)
Task / Job: These feel a bit short lived compared to a long running game server process. Also i'll want to use the term jobs later for managing workloads within GameStrut, so can't use that here.
Daemon / Service: These are not short lived like tasks or jobs so that's good, but they have the sense that there will just be one, and it starts with the machine. Whereas we'll be dynamically starting and stopping services as we deploy or scale, and we might be running multiple of the same thing.
Instance: This one is pretty good, but I think this will be confused later on with some online game terminology, like dungeon instances, so best to keep that free.
So now i'm free to start creating tables, or more factually, i'm free to rename the server table to machine and cleanup all the references...