How to Compile, Install, Start, and Manage LacServer

[bbosen]

How to Install, Start, and Manage the Linux Air Combat Server on your LINUX host

The Linux Air Combat Server ("The Server") is used by Linux Air Combat ("LAC") clients in support of multi-player online missions. As every copy of LAC simulates flight in any of the online, multi-player missions, it transmits the player aircraft's position, velocity, and orientation to The Server several times per second (usually 10 times per second). The Server then relays that information to all of the other players flying in the same Realm and Mission.

For every mission, the Server can support as many as 10 simultaneous players, relaying position, orientation, and velocity information among all of the active players so each player's copy of LAC can render all of the other aircraft appropriately. At the time of completion of the Server in 2024, LAC supported 10 distinct Missions in each of 32 distinct Realms. Each mission can support as many as 10 simultaneous online players, so the Server can theoretically support as many as 3200 simultaneous players. However, the maximum number of players that have actually connected simultaneously is only 40, so that theoretical maximum load remains unverified.

The Server is compiled from open-source "C" and "C++" source code, for use in the LINUX Operating System, relying on well-known, standardized operating system resources that were popular and widely supported in 2024.

To commence a new LAC Server, you will probably want to compile the source code on your LINUX hardware. Compilation is a straight-forward process that is familiar to experienced developers. Edit and use the included "go.sh" script to compile the source code. You will need to edit the small area of that file where it designates the exact location of the source code in your filesystem. When you run the appropriately edited "go.sh" script, your compiler will probably issue a dozen or more harmless "warning" messages that you may reasonably ignore. After compiling from within the usual file/folder organization that results from un-tarring our source archives, you'll find the compiled result in the "bin/Debug" folder beneath the source code folder. (If your compilation and linking operations were successful, the new file should display an appropriately updated date. You can just delete any older versions showing prior compilation dates.)

Your first test experience with the compiled LAC server should just exercise its "help" facility. From a command console like "bash", enter the folder where you've found or copied the executable. For our purposes in this document, we will assume that the executable is named "LacServer90".

Execute "LacServer90" from a command line according to well-established norms, and append "--help" to the command. Accordingly, your command line should look a lot like this:

./LacServer90 --help

If your compile and link efforts were successful, you should see a sensible, English-language report like the following:

=============== BEGIN LacServer Startup "help" message =============

Linux Air Combat Server.

Invalid command line parameter.

Usage:

LacServer [d#] [h] [v]

Valid command-line arguments are:

d# where # is an integer from 1 to 524287 with bit-coded debug level as follows:

INPACKETCOUNT 1
INTERPACKETCRLF 2
INPACKETIPANDPORT 4
INPACKETTIMESTAMP 8
MISSIONID 16
PACKETAGE 32
ERRORS 64
UDPSTATUS 128
CLIENTAGEDOUT 256
OUTPACKETTIMESTAMP 512
RESPONSETIME 1024
PEERPOSITION 2048
PEERDISTANCE 4096
PEEROUTOFRANGE 8192
OUTPACKETCOUNT 16384
FUNCTIONENTRYPOINTS 32768
REALM 65536
OUTPACKETIPANDPORT 131072
SKIPCOUNT 262144
ADMIN PACKETS 524288
GUN CAMERA LOGIC 1048576
DEBUGGING 2097152

Typical Debug settings are:
0 = no diagnostic output.
1 = InPacket count only.
279553 = Errors, MissionID, SkipCount, and Response Time
278531 = InPacket Count, OutPacket Count, SkipCount, CRLF between packets
2097151 = maximum details without DEBUGGING.
4194303 = maximum details with DEBUGGING.

h (Help Request. Displays this text.)
v (Version info request.)

=============== END LacServer Startup "help" message =============

As you can see, that text includes lots of instruction for valid command-line arguments. You can experiment with the "d#" value to force the LacServer to display helpful details if you need to debug something. Usually, for "production" use of LAC, you will want to issue a command like THIS:

./LacServer90 d0

Whereupon you sould see a response like THIS:

=============== Begin LacServer routine startup text =============

Linux Air Combat Server.

Entering debug level 0.
This will generate the following diagnostic output:

None. (No Diagnostic output at all.)

main() succesfully opened LacServerLog.txt.
Starting execute thread.

Ready to receive InPackets from LAC clients on UDP port 51100.

Press <ctrl-c> to terminate....</ctrl-c>

=============== End LacServer routine startup text =============

As you can see, this indicates that your LacServer is waiting for input from LAC players that have configured their "LacConfig.txt" files with the IP address of your LacServer.

You will need to teach your users to edit their LacConfig.txt configuration files so that they reference your LacServer instead of the default one. Have them look for THIS block of well-documeted text in their LacConfig.txt files:

============= BEGIN LacConfig.txt designating our default LacServer IP address =========

# If you are going to use LINUX AIR COMBAT on a network, you must configure the IP address
# of a Linux Air Combat Server or of one other computer also using LINUX AIR COMBAT. To do
# this using a numeric IP address like 192.34.59.172, you must enter four numbers into the
# next four Configuration Lines. For Example, if you want your computer to connect with
# another local LAC user for 2-player Head to Head activities or to another LAC server that
# is on your local LAN using IP address 192.168.1.2, you would enter 192 on the first of the
# next four lines, after ServerIpByte1of4 =. Then you would enter 168 on the second of
# those lines, 1 on the third line, and 2 at the end of the fourth line, after it says
# ServerIpByte4of4.

ServerIpByte1of4 = 192
ServerIpByte2of4 = 34
ServerIpByte3of4 = 59
ServerIpByte4of4 = 172

# You can use the four lines above to specify any numeric IP4 address, referencing any
# computer on the worldwide Internet. Since 2020, LAC's server has normally been hosted at IP
# address 192.34.59.172, so you could use those values. However, because that numeric IP
# addresses may change someday, you may need to change it sometime in the future.

# Note that the monthly cost of hosting the LAC Server at LinuxAirCombat.com is paid by
# the good people at AskMisterWizard.com and is derived from advertising revenue resulting
# from traffic to their web site. If they ever decide to cease this funding, the LAC server
# may disappear. In that case, you will always be able to enter the numeric IP address of
# some other player above and enjoy LAC's two-player Head-To-Head mode with him or her.

# Of course, because LAC's source code is published, it is also possible that somebody else
# may start hosting a LAC server through some other IP address. In that case, you could use
# that LAC server by entering its numeric IP address into the four configuration lines
# above.

============= END LacConfig.txt designating our default LacServer IP address =========

Have your users change the four lines commencing with "Server IpByte..." to reference your LacServer's public IP address instead of "192.34.59.172".

They will thereafter be able to find other LAC users that have done the same. As you begin supporting your users with your copy of LacServer, you may want to use its "d#" (Debug level) command-line argument to monitor their connection and data transfer events. You'll find this very interesting and helpful at first!

After awhile, though, you'll want to turn off that debugging (Execute with a command line like "./LacServer90 d0")

Once you are satisfied that your LacServer is running as expected without problems, you'll eventually reach a point where you'd like to just leave it running constantly while you ignore it so you can move on to other things. I host the default LacServer on a commercial service in New York City managed by "DigitalOcean.com", and I have found that I only need check on it about once a month, just to ensure that it hasn't used up all of the available disk space with its log files. When that happens, I take steps to kill the LacServer process, delete the huge "LacServerLog.txt" file that it accumulates, and then re-start the LacServer.

I have learned how to start the LacServer in a manner that keeps it running even after I log off from the DigitalOcean server hosting it. Starting from a situation where my server is NOT yet running, here is how I do that:

Step 1: I log on to my server host's LINUX operating system. My server host has been given the public DNS name "LinuxAirCombat.com". For my username on that operating system, I chose the name "LacServer". Accordingly, in my case, the ssh ("secure shell") command line I use is:

ssh LacServer@LinuxAirCombat.com

After entering my password according to longstanding norms, I am greeted with a bash "secure shell" command prompt as any experienced LINUX user would expect.

Step 2: I use the "cd" command as necessary to change my directory to the appropriate "~bin/Debug" folder where the server executable is found.

Step 3: I invoke a new (additional) "bash" shell with a new command "/bin/bash". My subsequent commands in steps 4, 5, 6, and 7 will use that new bash shell. I will kill that new bash shell when I get to step 8, which will return control to the original bash shell I first accessed at the end of Step 1.

Step 4: I use "ps" to determine the process id of my new bash shell, because I know I will need that new process id when I get to step 8 in this sequence. (I write that process id number down for use in a few minutes.)

Step 5: From within that additional new bash shell, I invoke my LacServer with a command like this:

./LacServer90 d0

Step 6: I verify that my LacServer is operating by using two additional computers to fly together in one of the online missions, confirming that each player can see the other online.

Step 7: From a DIFFERENT Linux machine (or from a different window of the same LINUX machine used for steps 1 through 5), I use ssh again to login to my "LinuxAirCombat.com" server as "root". For my situation, the command line looks like this:

ssh Root@LinuxAirCombat.com

After satisfying the demand for my root password as expected, I am greeted with another bash "secure shell" root command prompt.

Step 8: From that new root command shell, I kill the "bash" shell from which I launched my LacServer process as described in Steps "4" and "5" above. As an example of the command I use, let's assume that the process id recorded step "4" was "22502". The command I would use would be:

kill -9 22502

As you can see, that "kill" command designates a priority of "9" and references the process id of the shell from which I launched my LacServer process. This leaves that process running without an associated bash shell.

Step 8: I verify that my LacServer is still operating by repeating Step 6. If two distinct players can still fly together in one of the online missions, I know that the server is still running.

Step 9: I Log out of any and all connections used in the prior steps. The LacServer remains running and anybody can use it with no need for you to monitor it!